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THE  OPERATIONAL  APPROACH 
TO  REQUIREMENTS  SPECIFICATION 
FOR  EMBEDDED  SYSTEMS 

0.  INTRODUCTION 

Recently  the  study  of  system  requirements  has  emerged  as  a  major  area  of 
research  in  software  engineering.  It  has  become  clear  that  the  stated 
requirements  for  a  system  have  tremendous  Impact  on  the  quality  and  usefulness 
of  the  ultimate  product,  and  on  the  efficiency  and  manageability  of  its 
development.  Yet,  despite  their  leverage,  relatively  little  is  known  about 
deriving  and  specifying  good  sets  of  requirements. 

At  the  same  time,  the  prominence  of  "embedded"  (roughly  equivalent  to 
"real-time")  systems  has  been  Increasing,  due  largely  to  hardware  advances 
which  have  made  them  feasible  for  a  broader  category  of  applications  chan  ever 
before.  We  will  argue  that  embedded  systems  are  characterized  by  the  urgency 
of  their  performance  requirements;  to  the  extent  that  all  computer  systems 
would  benefit  from  the  ability  to  state  and  satisfy  performance  requirements, 
even  very  specialized  knowledge  about  embedded  systems  can  be  useful  to 
developers  of  other  types  of  system. 

This  paper  presents  a  new  approach  to  the  problem  of  specifying  the 
requirements  for  embedded  systems.  It  offers  a  substantial  Increase  in 
formality,  expressive  power,  and  usefulness  (in  terms  of  the  kinds  of 
processing  that  can  be  performed  on,  and  the  Information  that  can  be  derived 
from,  a  requirements  specification)  over  the  current  widely  known  requirements 
technologies . 

This  paper  Is  self-contained.  We  give  brief  Introductions  to  the 
subjects  of  requirements  and  embedded  systems,  explain  and  motivate  our 
approach  In  detail,  and  then  present  a  formal  requirements  language  embodying 
it.  Four  systems,  comprising  a  representative  sample  of  embedded  system 
structures  and  properties,  are  used  in  examples  throughout.  Finally  there  Is 
an  Interim  evaluation  of  Che  approach,  and  plans  for  future  research. 
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1.  THE  REQUIREMENTS  PROBLEM 

1.1.  The  role  of  requirements  In  the  system  life  cycle 

The  development  of  a  computer  system  begins  with  the  perception  of  a  need 
for  It.  During  the  requirements  phase,  analysts  should  arrive  at  a  deep 
understanding  of  that  need,  and  propose  a  system  to  fill  it.  The  product  of 
the  requirements  phase  Is  the  requirements  specification,  which  plays  a  unique 
and  crucial  role  In  the  rest  of  development.  It  states  what  system  is  to  be 
developed,  at  what  costs,  and  under  what  constraints. 

The  project  cannot  be  a  complete  success  unless  the  requirements  have  the 
Informed  consent  of  everyone  who  will  be  involved,  including  members  of  the 
development  organization  (designers,  programmers,  and  managers),  the 
originating  organization  (the  people  who  determine  the  cost  and  value  of  the 
system:  managers  of  an  operatlon—if  the  system  Is  being  developed  for 
Internal  use,  or  salespeople--lf  the  system  will  be  offered  as  a  product),  and 
the  ultimate  users  of  the  system.  This  consensus  can  only  be  achieved  through 
feedback  and  negotiation,  with  preliminary  versions  of  the  requirements 
specification  being  the  major  vehicle  of  communication. 

During  design  and  Implementation,  the  requirements  specification  defines 
the  "top"  for  top-down  design,  and  the  product  toward  which  management  effort 
Is  aimed.  At  the  end  of  development,  it  Is  the  standard  against  which  the 
system  Is  compared  for  success  or  failure,  acceptance  or  rejection. 

Requirements  are  often  neglected,  for  reasons  that  are  all  too  familiar; 
lack  of  awareness  of  their  importance  (which  Is  disappearing),  lack  of  useful 
requirements  analysis  and  specification  techniques,  and  natural  reluctance  to 
Incur  costs  and  delays  at  the  beginning  of  a  project.  Yet  the  consequences  of 
this  shortsightedness,  which  Include  cancelled  projects  or  unprofitable 
products,  unhappy  users,  chaotically  structured  systems,  budget  and  schedule 
overruns  as  endless  changes  are  made,  and  even  lawsuits,  are  so  serious  that 
no  one  Involved  In  software  engineering  can  afford  to  ignore  them.  Other 
Introductions  to  the  role  of  requirements  In  system  development  can  be  found 
In  (Boehm  76),  [Bell  &  Thayer  76],  (Ross  &  Schoman  77],  [Yeh  £t  80], 
[Henlnger  79],  [Balzcr  &  Goldman  79],  and  (Davis  &  Rauscher  79]. 

It  should  be  noted  that  even  with  the  most  optimistic  view  of  current 
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progress  on  requirements  analysis  and  specification,  In  which  problems  of 
communication  and  complexity  can  be  solved,  certain  other  problems  will  remain 
very  difficult  to  deal  with.  One  Is  that  vital  decisions  must  be  based  on 
forecasts  of  costs  and  even  feasibility,  while  such  forecasting  Is  perhaps  the 
weakest  point  of  our  software  technology.  Another  Is  that  the  requirements 
are  constantly  changing,  even  as  we  try  to  write  them  down.  And  systems  that 
are  used  evolve  continually  throughout  their  lifetimes  ((Belady  &  Lehman  79]), 
creating  "maintenance"  costs  which  may  eventually  dwarf  those  of  Initial 
development. 

As  consciousness  of  the  economic  and  technical  importance  of  evolution  In 
the  system  life  cycle  grows,  we  may  develop  a  new  concept  of  the  life  cycle 
based  on  iterated  (re)developmenta ,  large  and  small,  as  in  [Conn  80).  In  such 
a  model,  the  requirements  specification  will  evolve  with  the  system,  serving 
throughout  Its  life  as  definition,  documentation,  and  contract.  Needless  to 
say,  this  expanded  role  will  place  even  greater  demands  on  the  quality  and 
modifiability  of  our  requirements  specifications. 

1.2.  Goals  for  requirements  specifications 

Progress  In  software  engineering  has  almost  always  been  made  from  the 
bottom  up:  from  machine  language  to  axiomatic  specifications,  for  example,  wo 
have  proceeded  first  by  learning  to  do  something,  and  then  by  understanding  it 
well  enough  to  find  suitable  abstractions  of  it.  This  paper  takes  the  sane 
approach  to  requirements.  It  seems  unlikely  that  we  will  find  really 
effective  techniques  for  requirements  analysis  before  we  know  how  to  write  a 
good  requirements  specification  recording  the  results  of  that  analysis. 
Therefore  we  will  concentrate  on  specification  techniques  (although  useful 
results  on  specification  cannot  help  but  suggest  analytic  methods  and 
principles) . 

The  characteristics  of  a  good  requirements  specification  can  be  Inferred 
from  the  things  that  will  be  done  with  it.  Since  the  latest  version  (to  call 
It  a  "final"  version  Is  to  Ignore  the  reality  of  system  evolution)  must  be 
obtained  by  Iterative  communication  and  negotiation,  the  specification  must  be 
modifiable.  It  must  also  be  easy  for  people  to  understand. 

What  would  make  a  specification  understandable?  Perhaps  the  biggest 
barrier  to  understanding  large  systems  Is  complexity,  and  so  the  specification 
must  decompose  complexity  In  every  appropriate  way.  Three  forms  of 


ahfi  tract  Ion , 


deconposlt Ion  are  already  rami  liar  In  vartona  contexts: 

partition,  and  projection  (Figure  1).  Ahatract^on  forms  a  tilcrarcliy  of 

repreaentations  in  which  detail  is  suppressed  at  the  higher  levels  and 

elaborated  at  the  lower  levels.  Partition  Is  used  to  represent  the  whole  as 
the  sum  of  Its  parts,  making  It  possible  to  examine  the  parts  one  at  a  time. 
Projection  represents  the  whole,  but  only  with  respect  to  a  subset  of  Its 
properties.  The  obvious  example  of  a  projection  is  a  two-dimensional 
architectural  drawing  of  one  view  of  a  three-dimensional  building.  A 
requirements  specification  language  must  support  all  three  kinds  of 

decomposition,  alone  and  In  combination. 

Good  decomposition  of  complexity  (procedures,  data  modules,  monitors, 
etc.)  makes  It  possible  to  understand  programs  by  reading  them.  The  other  way 
that  people  come  to  understand  programs  is  by  testing  then.  Testing  is  so 
essential  to  programming  that  It  seems  foolish  to  do  without  it  at  any  stage 
of  development.  Therefore  requirements  specifications  should  be  executable , 
and  thus  subject  to  validation  by  testing.  The  potential  benefits  are  very 
great,  because  executable  requirements  can  be  "debugged",  used  to  put  on 
behavioral  demonstrations  for  customers,  turned  into  "fast  prototypes",  and 
more  (see  3.3). 

Finally,  a  specification  intended  to  be  understood  by  people  should  be 
Intuitive,  l.e.  It  should  be  written  so  as  to  assist  the  memory  and  elicit 
tacit  knowledge  (see  the  "human  factors"  section  of  [Ych  e^  80]  for  a 

survey  of  psycholo 'leal  findings  concerning  requirements). 

The  other  major  purpose  for  which  a  r*-*quirenents  sped  f  icac  ion  is  used  is 
constraining  the  target  system  of  the  development  project.  To  do  this  well  it 
should  be  precise ,  unambiguous ,  Internally  consistent ,  and  sufficiently 
complete.  It  should  also  be  minimal ,  l.e.,  define  the  smallest  set  of 

properties  that  will  satisfy  the  users  and  originators.  Otherwise  the 
specification  may  over-constraln  the  target  system,  so  that  some  of  the  best 
solutions  to  design  problems  are  unnecessarily  excluded. 

The  specification  must  also  be  used  to  accept  or  reject  the  final 
product.  If  verification  la  to  be  used  for  this  purpose,  the  specification 
must  be  formally  manlpulable  and  therefore  formal  (although  formality  has 
already  been  Implied  by  precision,  lack  of  ambiguity,  consistency,  and 
executablllty) .  If  acceptance  testing  Is  to  be  used,  the  testable  behavior  of 
executable  requirements  will  provide  a  concrete  standard  to  which  the 


ImplementaClon  can  he  compared. 

The  remainder  of  this  paper  is  concerned  with  a  requirements 
specification  approach  (and  language)  that  promises  to  help  us  achieve  many  of 
these  goals.  It  is  also  somewhat  specialized  for  a  particular  class  of 
systems,  namely  .... 
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2.  EMBEDDED  SYSTEMS 

Common  examples  of  embedded  systems  are  Industrial  process-control 
systems,  flight-guidance  systems,  switching  systems,  patient-monitoring 
systems,  radar  tracking  systems,  ballistic-missile-defense  systems,  and 
data-collection  systems  for  experimental  equipment.  The  class  of  embedded 
systems  Is  an  Important  one,  partly  because  it  already  Includes  some  of  our 
oldest  and  most  complex  computer  applications,  and  partly  because  it  Is 
expanding  rapidly  in  volume  and  variety  as  a  result  of  the  microprocessor 
revolution. 

2.1.  What  makes  a_  system  "embedded"? 

The  term  "embedded"  was  coined  by  the  U.S.  Department  of  Defense  in 
conjunction  with  its  common  language  (Ada)  development  project.  "Embedded" 
refers  to  the  fact  that  these  systems  are  embedded  in  larger  systems  whose 
primary  purposes  are  not  computation,  but  this  Is  actually  true  of  any  useful 
computer  system.  A  payroll  program,  for  Instance,  is  an  essential  part  of  a 
business  organization,  which  is  a  system  whose  primary  purpose  is  selling 
products  at  a  profit. 

The  common  concept  that  unites  the  systems  we  choose  to  call  "embedded" 
is  process  control :  providing  continual  feedback  to  an  unintelligent 
environment.  This  "theme"  is  easily  recognized  in  flight-guidance  systems  and 
switching  systems;  even  in  a  patient-monitoring  system,  sick  patients  are  not 
exercising  their  intelligence  in  Interacting  with  the  system,  and  nurses  can 
be  viewed  as  providing  a  mechanical  extension  to  the  system's  feedback  loop. 

The  continual  demands  of  an  unintelligent  environment  cause  these  systems 
to  have  relatively  rigid  and  important  performance  requirements,  such  as 
real-time  response  requirements  and  "fall-safe"  reliability  requirements.  It 
seems  that  this  emphasis  on  performance  requirements  Is  what  really 
characterizes  embedded  systems,  and  causes  us  to  be  more  aware  of  their 
environments  than  we  are  for  other  types  of  system.* 

Figure  2  shows  an  Informal  classification  of  systems,  based  on  properties 
that  show  up  at  the  requirements  level.  Requirements  for  "support  systems" 
are  generally  much  less  definite  than  requirements  for  applications  systems. 
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And  while  the  performance  requirements  for  embedded  systems  may  be  couched  in 
absolutes,  the  performance  requirements  for  support  systems  will  be  relative 
to  resources  and  resource  utilization,  and  the  performance  requirements  for 
data-processlng  systems  will  be  relative  to  load,  resources,  and  psychological 
factors.  The  most  complex  systems,  such  as  nationwide  airline-reservation 
systems,  should  probably  be  viewed  as  having  subsystems  of  all  three  types. 

t 

2.2.  The  special  problems  of  embedded  systems 

The  special  nature  of  embedded  systems  exacerbates  many  software 
engineering  problems,  and  thus  demands  particular  attention  even  during  the 
requirements  phase. 

Few  organizations  have  logged  as  much  experience  with  embedded  systems  as 

the  Department  of  Defense,  which  spends  56  per  cent  of  its  approximately  3 

billion  dollar  annual  software  budget  on  them  ([Fisher  78]).  Here  is  a 

pointed  summary  of  that  experience: 

Embedded  computer  software  often  exhibits  characteristics  that  are 
strikingly  different  from  those  of  other  computer  applications.  The 
programs  are  frequently  large  (50,000  to  100,000  lines  of  code)  and 
long-lived  (10  to  15  years).  Personnel  turnover  is  .rapid,  typically 
two  years.  Outputs  are  not  just  data,  but  also  control  signals. 
Change  Is  continuous  because  of  evolving  system  requirements — annual 
revisions  are  often  of  the  same  magnitude  as  the  original 
development  ([Fisher  78]). 

Clearly  coping  with  complexity  and  change  will  not  be  easier  in  the  domain  of 
embedded  systems. 

In  addition  to  the  performance  requirements,  which  have  alre’  iy  b'^en 
established  as  a  major  distinguishing  factor,  embedded  systems  are  especially 
likely  to  have  stringent  resource  requirements.  These  are  requirements  on  the 
resources,  mainly  physical  In  this  case,  from  which  the  system  is  constructed. 
This  Is  because  embedded  systems  are  often  Installed  in  places  (such  as 
satellites)  where  their  weight,  volume,  or  power  consumption  must  be  limited, 
or  where  temperature,  humidity,  pressure,  and  other  factors  cannot  be  as 
carefully  controlled  as  In  the  traditional  machine  room. 

The  Interface  between  an  embedded  system  and  its  environment  tends  to  bo 
complex,  asynchronous,  highly  parallel,  and  distributed.  This  is  another 
direct  result  of  the  "process  control"  concept,  because  the  environment  is 
likely  to  consist  of  a  number  of  objects  which  interact  with  the  system  and 
each  other  In  asynchronous  parallel.  Furthermore,  it  is  probably  the 
complexity  of  the  environment  that  necessitates  computer  support  in  the  first 
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place  (consider  an  alr-traff Ic-control  system)!  This  characteristic  makes  the 
requirements  difficult  to  specify  in  a  way  that  is  both  precise  and 
comprehensible. 

Finally,  embedded  systems  can  be  extraordinarily  hard  to  test.  The 
complexity  of  the  system/envlronraent  Interface  is  one  obstacle,  and  the  fact 
that  these  programs  often  cannot  be  tested  in  their  operational  environments 
is  another.  It  Is  not  feasible  to  test  flight-guidance  software  by  flying 
with  it,  nor  to  test  balllstlc-misslle-defense  software  under  battle 
conditions. 

2.3.  Representative  examples  of  embedded  systems 

The  following  systems,  when  developed  appropriately,  represent  a  wide 
variety  of  structures  and  problems  typical  of  embedded  systems.  They  will  be 
used  in  examples  throughout  the  paper. 

2.3.1.  An  airline-reservation  system 

This  is  an  on-line  (Interactive)  database  system  used  for  airline 
reservations.  It  is  accessed  from  10,000  terminals  across  the  country,  and 
must  process  an  average  of  200  transactions  per  second  (these  and  other 
quantities  are  taken  from  [Knight  72)). 

Systems  of  this  type  are  not  always  treated  as  embedded — rather,  their 
data-processing  nature  is  emphasized,  and  the  users  are  expected  to  accomodate 
themselves  to  whatever  level  of  performance  the  system  offers.  We  emphasize 
its  embedded-system  characteristics  by  requiring  certain  absolute  levels  ot 
performance,  and  by  taking  the  physical  effects  of  geographical  dispersion 
into  account  at  the  requirements  level. 

2.3.2.  A  process-control  system 

This  system  monitors  three  machines  in  a  factory;  while  fairly  simple,  it 
has  an  interesting  variety  of  activities.  A  relatively  complete  specification 
of  it  can  be  found  In  [Zave  &  Yeh  81] . 

Conditions  local  to  individual  machines  may  call  for  minor  adjustments, 
which  are  done  automatically  by  the  system.  Conditions  arising  in  the  factory 
as  a  whole,  however,  may  be  quite  dangerous,  and  are  responded  to  by  a  human 
operator.  The  system's  responsibility  is  to  detect  these  conditions  and  sound 
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an  alarm. 

The  system  also  keeps  information  about  factory  conditions,  which  is  used 
for  two  purposes:  printing  reports  on  production  and  consumption  of  raw 
materials,  and  answering  queries  about  machine  and  factory  status  from  the 
operator  (particularly  when  the  alarm  has  sounded). 

2.3.3.  A  patient-monitoring  system 

Patient-monitoring  systems  are  often  used  as  examples  in  the  requirements 
literature,  although  the  usual  treatment  is  naive.  (Primarily,  only  the 
data-oriented  aspects  of  the  system  are  considered.)  The  system  reads  sensors 
attached  to  patients  in  an  intensive-care  unit  of  a  hospital.  The  system 
displays  a  warning  message  on  a  CRT  screen  if  a  sensor  value  falls  outside  of 
a  safe  range  or  if  a  sensor  appears  to  be  malfunctioning.  Interesting  sensor 
values  are  stored  in  a  database  which  can  be  queried  from  the  terminal.  The 
frequency  with  which  a  sensor  is  read,  the  safe  range  for  a  sensor  value,  and 
the  criteria  for  keeping  readings  in  the  database,  can  all  be  adjusted  by 
doctors  and  nurses  from  the  terminal. 

2.3.4.  The  Air  Force  Weapons  Effectiveness  Testing  (AFV.^T)  system 

This  system  (ultimately  realized  under  the  name  "'.vESTE" )  was  an  early 
real-time  system  which  suported  quantitative  testing  of  U.S.  military 
(conventional  warfare)  capability  (see  Figure  3).  Its  requirements  document 
([Air  Force  65])  is  a  fruitful  source  of  bad  examples  and  unsolved 
requirements  problems. 

Tests  were  military  exercises  involving  "test  elements”  such  as 
airplanes,  ships,  tanks,  and  ground  defense  positions  (some  playing  the  role 
of  enemy  forces),  confined  to  a  circle  centered  on  Eglin  Air  Force  Base  in 
Florida.  Test  elements  communicated  with  a  central  site  through  'lltary 
standard  radio  equipment,  plus  a  contractor-supplied  communications  network. 

During  a  test,  moving  elements  would  send  periodic  notifications  of  their 
positions  to  the  central  site.  Mock  firings  of  weapons  would  also  cause 
messages  to  be  sent,  supplying  all  relevant  parameters  such  as  the  direction 
of  aim.  The  central  system  would  simulate  the  battle  in  real  time, 
determining  which  of  the  mock  firings  would  have  resulted  in  "kills".  The 
results  of  the  simulation  were  (a)  used  to  display  the  course  of  the  battle  on 


graphics  scopes  for  the  benefit  of  officers  In  a  control  roon,  (b)  dunped  onto 
archival  storage  for  later  analysis,  and  (c)  used  to  send  "kill"  notifications 
to  "killed"  test  elements  in  the  field.  They  would  then  react  with  a  flashing 
light  or  loud  noise,  and  cease  to  participate  In  the  battle. 
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3.  AN  "OPERATIONAl."  APPROACH 

The  approach  taken  In  this  paper  Is  to  specify  the  requirements  for  an 
embedded  system  with  an  explicit  model  of  the  proposed  system  interacting  with 
an  explicit  model  of  the  system's  environment.  Both  submodels  consist  of  sets 
of  asynchronously  interacting  digital  processes,  although  some  of  the 
processes  in  the  environment  model  may  represent  discrete  simulations  of 
nondlgltal  objects  such  as  people  or  machines.  The  entire  model  is 
executable,  and  the  internal  computations  of  the  processes  are  specified  in  an 
applicative  language. 

We  call  this  the  "operational"  approach  because  the  emphasis  on 
constructing  an  operating  model  of  the  system  functioning  in  its  environment 
provides  its  primary  flavor.  It  has  been  embodied  in  a  Specification  Language 
which,  since  it  is  based  on  the  ideas  above  and  is  therefore  Process-oriented, 
Applicative,  and  Snterpretable  (executable),  is  named  PAISLey. 

In  the  remainder  of  this  section,  the  basic  ideas  behind  the  operational 
approach  will  be  explained,  illustrated,  and  justified  in  detail.  Section  4 
addresses  the  apparent  disadvantages  of  the  operational  approach,  and  Section 
5  defines  PAISLey. 

3.1.  Explicit  modeling  of  the  environment 

Figure  4  is  a  diagram  of  the  processes  and  interactions  in  part  of  the 
requirements  model  for  a  patient-monitoring  system.  The  "patient" ,  "nurse" , 
and  "doctor"  processes  are  all  digital  simulations  of  these  natural  objects, 
representing  (obviously)  only  the  roles  played  by  these  people  with  respect  to 
patient-monitoring.  Thus  the  nurse's  behavior  includes  only  (a)  treating  a 
patient  because  of  a  warning  from  the  system,  (b)  adjusting  a  sensor  because 
of  a  warning  from  the  system,  and  (c)  Interacting  with  the  system  (via  the 
"crt-terminal"  process)  in  any  way  requested  of  him  during  Interactions  with  a 
doctor. 

The  "sensor"  and  "crt-terminal"  processes  represent  analog-to-digltal 
conversion  devices.  They  are  considered  parts  of  the  environment  rather  than 
the  proposed  system  simply  because  they  are  "given":  the  contractor  need  not 
supply  them,  nor  can  he  change  what  they  are. 
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The  "reader"  process  reads  (and  t  imcsi.impn )  sensor  Jiita  at  Intervals  lU 
real  time  specified  from  the  terminal.  The  "monitor"  process  c\iecka  the  data 
according  to  criteria  specified  from  the  terminal,  sending  warning  messages  If 
a  health  factor  falls  outside  the  safe  range,  or  If  a  sensor  seems  to  be 
malfunctioning.  It  also  sends  sufficiently  Interesting  data  to  the  "database" 
process,  which  responds  to  queries  from  the  terminal  and  also  purges  old  data 
to  maintain  Itself  at  a  reasonable  size. 

Including  an  explicit  model  of  the  environment  has  several  advantages  for 
requirements  specification.  The  reason  that  the  interface  between  an  embedded 
system  and  Its  environment  Is  complex,  asynchronous,  highly  parallel,  and 
distributed  is  that  It  consists  of  Interactions  among  a  number  of  objects 
which  exist  In  parallel,  at  different  places,  and  are  not  synchronized  with 
one  another.  Organizing  these  Interactions  around  the  objects  (processes) 
which  take  part  In  them  Is  an  effective  way  to  decompose  this  sort  of 
complexity.  Furthermore,  assumptions  and  expectations  on  both  sides  of  the 
boundary  can  be  documented.  The  result  Is  a  specification  which  Is  far  more 
precise  and  yet  comprehensible  than  could  be  obtained  by  treating  either  side 
of  the  interface  as  a  "black  box",  which  is  what  happens  when  the  environment 
Is  not  modeled. 

Another  reason  for  having  an  environment  model  Is  that  the  environment 
(when  construed  broadly  enough)  Is  the  source  of  all  changes  to  the  system. 
Modeling  it  Is  therefore  a  promising  way  to  anticipate  changes  and  enhance  the 
modifiability  of  both  specification  and  target  system. 

A  simple,  but  not  unimportant,  example  of  this  has  to  do  with  the 
environment /system  boundary.  After  requirements  for  a  patient-monitoring 
system  along  the  lines  of  Figure  4  have  been  specified,  it  may  be  decided  that 
the  contractor  should  supply  terminals  and  sensors  after  all.  The  change  to 
the  specification  Itself  will  be  trivial,  since  the  boundary  is  arbitrarily 
placed,  and  not  really  part  of  the  executable  model.  More  Importantly,  most 
of  the  "new”  analysis  work  will  have  already  been  done:  the  analysts  will 
understand  fully  (l.e.  from  both  sides)  the  function  of  this  equipment,  and 
will  probably  be  very  aware  of  any  shortcomings  that  should  be  corrected,  now 
that  the  freedom  exists  to  do  so. 

The  final  advantage  of  specifying  the  environment  is  that  manv 
performance  constraints  are  most  naturally  attached  there.  The 
patlent-monitorlng  system  has  (among  others)  response-time  requirements  on 


database  queries,  and  a  requiremenc  tn  be  able  to  handle  a  certain  load  of 
sensors  and  terminals.  The  response  requirement  is  most  dlrectlv  expressed  as 
a  time  limit  on  the  component  of  the  terminal  specification  which  waits  for 
the  response  after  sending  a  query.  The  load  is  largely  a  function  of  the 
numbers  and  output  rates  of  sensors  and  terminals,  and  so  specifications  of 
sensors  and  terminals  must  be  a  large  part  of  specifying  any  load  requirement. 

The  other  significant  aspect  of  constructing  an  environment  model  is  that 
it  is  a  valuable  tool  for  requirements  analysis ,  as  well  as  specification.  In 
fact,  the  best  way  to  analyze  requirements  may  be  to  start  with  the 
environment  model,  and  work  "outslde-ln"  to  a  proposed  system  which  supports  a 
desirable  mode  of  operation  in  the  environment.  The  extreme  case  i.s 
automation  of  an  existing  manual  system — in  the  absence  of  changes  to  existing 
procedures,  the  requirements  can  be  derived  simply  by  modeling  the  current 
operation,  and  drawing  a  boundary  to  distinguish  the  automatable  part!  [Veh 
et  al.  79a]  and  [Yeh  ^  a^.  79b]  both  discuss  "conceptual  models",  which  are 
models  of  system  environments  constructed  for  the  purpose  of  requirements 
analysis . 

In  the  patient-monitoring  system,  since  only  the  "sensor”  and 
"crt-terminal”  processes  Interact  directly  with  the  proposed  computer  system, 
only  these  are  necessary  for  precise  specification  of  the  system  interface. 
The  ’’patient'' ,  "nurse",  and  "doctor"  processes  appear  strictly  as  vehicles  for 
requirements-  analysis.  Wondering  how  doctors  and  nurses  interact  leads  the 
analyst  to  ask  which  kinds  of  information  a  doctor  expects  to  get  from  a  nurse 
on  duty,  and  which  kinds  he  would  like  to  find  in  the  database.  '.Pondering  how 
nurses  interact  with  patients  and  the  display  leads  the  analyst  to  ask  how  the 
display  screen  should  be  allocated  to  medical  histories  versus  emergence 
messages,  how  often  warnings  concerning  an  ongoing  crisis  need  be  displayed, 
and  whether  information  from  the  monitoring  system  is  needed  at  the  patient's 
bedside.  These  questions  are  never  asked  (or  answered)  in  the  numerous 
treatments  of  patient-monitoring  systems  appearing  in  the  requirements 
literature. 

Even  if  the  analysts  can  achieve  understanding  of  the  requirements  in 
some  other  way,  early  concentration  on  the  environment  may  load  to  better 
communication  with  users  (who  are  much  more  interested  in  their  environment 
than  your  system),  and  more  open-minded  problem-solving,  unbiased  by 
preconceived  notions  or  similar  systems  the  analysts  have  worked  on. 


3.2.  Processes 


Another  key  festure  of  the  operatton.il  approach  Is  that  the  primary  units 
of  Specification  are  processes.  A  process  Is  a  simple,  abstract 
representation  of  autonomous  (distributed)  digital  conputat  Inn .  It  Is 
specified  by  supplying  a  "state  space",  or  set  of  all  possible  states,  and  j 
"successor  function"**  on  that  state  space  which  defines  the  successor  state 
for  each  state.  It  goes  through  an  infinite  sequence  of  states  (although  a 
"halting"  process  can  be  specified  by  having  it  go  into  a  distinguished 
"halted"  state  which  It  will  never  leave),  asynchronously  with  respect  to  all 
other  processes  (Figure  5). 

A  process  is  cyclic,  with  Its  successor  function  describing  its  natural 
cycle.  The  natural  cycle  of  a  process  simulating  a  sick  patient,  for 
instance,  would  be  a  single  step  of  the  discrete  simulation  algorithr.  The 
successor  function  of  such  a  process  might  be  declared  as: 

patient-cycle;  PATIENT-STATE  — >  PATIENT-STATE, 
where  the  set  "PATIENT-STATE",  which  Is  Its  domain  and  range  and  also  r'e 
state  space  of  the  process,  contains  values  encoding  possible  states  of  the 
patient  between  almulatlon  steps.  The  natural  cycle  of  the  " ioetpr"  process 
might  be  to  take  one  action,  either  asking  one  question  of  a  nurse,  giving  me 
order  to  a  nurse,  or  taking  part  in  one  transaction  vith  the 

patient-monitoring  system. 

There  can  be  no  question  about  the  generality  of  processes.  They  were 
originally  used  as  abstractions  of  concurrent  activities  within 
multiprogramming  systems  ((Horning  4  Randell  73)),  and  many  recent  artirhs 
have  shown  that  they  can  be  used  to  represent  1/0  devices,  data  -.cdules, 
tasks,  monitors,  buffers,  or  any  other  identifiable  structure  within  a 
computer  system  (e.g.  (Hoare  78 j,  (Brinch  Hansen  78),  [Mao  4  Yeh  80'). 

Process-based  models  of  computation  have  been  the  focus  of  extensive 
theoretical  work  and  the  language  Smalltalk  ((Ingalls  78) ).  Our  varied 

examples  are  persuasive  evidence  chat  the  notion  of  digital  slmiilatlon  of 

nondlgltal  objects  Is  similarly  powerful  In  describing  the  envl ronnent s  of 
computer  systems. 

The  appropriateness  of  using  processes  to  specify  requirements  for 
embedded  systems  is  based  on  our  observation  that  In  these  systems, 
asynchronous  parallelism— among  environment  objects,  between  envirnnnent 
objects  and  the  system,  and  within  the  system  (if  only  for  reasons  of 
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performance) — occurs  naturally  at  the  reguirenents  level.  One  happy  result  of 
recognizing  that  parallelism,  by  using  processes  as  the  specification  unit,  is 
environment  specifications  which  should  he  highly  intuitive,  even  to  naive 
users.  This  is  because  they  are  populated  by  identifiable  models  of  the  sane 
autonomous,  interacting  objects  from  which  the  real  world  is  made. 

Perhaps  the  best  way  to  appreciate  processes  is  to  consider  the 
alternatives:  representations  of  processing  found  in  other  requirements 
languages.  The  one  most'  commonly  found  in  requirements  documents  is 
"dataflow".  Dataflow  diagrams  show  major  system  functions,  and  identify  the 
data  structures  which  are  their  Inputs  and  outputs  (e.g.  Figure  6).  Dataflow 
is  the  basis  of  PSL/PSA  ((Telchroew  &  Hershey  77])  and  SADT  ([Ross  77],  [Ross 
4  Schoman  77]),  and  has  probably  been  rediscovered  thousands  of  times  by 
isolated  requirements-wrlters. 

Dataflow  oiay  be  adequate  for  many  data-processing  systems,  such  as  the 
one  depicted  in  Figure  6.  This  is  because  major  subfunctions 
("check-inventory",  "scnd-lnvolce")  are  Implemented  as  major  subprograms,  and 
subprograms  are  invoked  in  some  Implicitly  understood  sequence,  whenever  their 
input  files  are  ready. 

Dataflow  is  seriously  Inadequate  for  embedded  systems,  however,  because 
control  is  all-important  in  embedded  systems,  and  takes  a  variety  of  forms 
which  are  not  captured  by  the  simplistic  notion  of  control  implicit  in 
dataflow.  If  the  system  in  Figure  6  had  the  "on-line"  character  and 
performance  requirements  of  an  embedded  system,  here  are  some  of  the  problems 
we  might  encounter  with  the  dataflow  approach:  (1)  A  distinction  must  be  made 
between  Inputs  which  are  always  present  (such  as  the  " I NTF.'.'inRy "  database)  and 
Inputs  which  Invoke  a  function  whenever  a  new  Instance  appears  (such  as 
"PURCHASE-ORDER").  The  situation  is  even  more  compl'^x  when  there  Is  an  input 
value  (such  as  the  current  output  of  a  sensor  attached  to  a  hospital  patient) 
which  la  always  available,  but  only  read  at  certain  real-time  intervals  (and 
the  Interval  Itself  is  a  variable  stored  in  some  system  database).  (.2) 
Functions  (such  as  "process-account-order"  and  "process-payment")  may  have  to 
be  executed  concurrently  to  meet  performance  requirements,  in  which  case  they 
must  synchronize  their  uses  of  shared  resources  or  databases  (such  as 
"ACCOUNTS").  (3)  Functions  may  no  longer  execute  in  a  predefined  sequence 
(because  of  simultaneous  access  from  multiple  terminals,  the  need  for  Internal 
housekeeping,  etc.),  and  so  a  complex  interplay  of  events  and  states  must  he 


•nclclpatcd.  With  so  many  dspartures  fron  the  kind  of  Information  directly 
txprssssble  In  s  dataflow  diagram.  It  becomes  leas  and  less  likely  that 
dataflow  can  provide  a  meaningful  characterization  of  the  system. 

The  control  arrow  In  SADT  adds  an  explicit  representation  of  control  to 
dataflow  diagrams  (an  Illuminating  discussion  of  Its  significance  can  be  found 
In  [Ross  77)),  but  Its  Informality  prevents  It  from  being  precise  or 
expressive  enough  for  embedded  systems.  Processes  and  their  Interactions,  on 
the  other  hand,  are  well-suited  to  the  task  of  specifying  complex  control,  as 
would  be  expected  from  their  historical  origins  In  the  specification  of 
operating  systems. 

Other  notions  of  control  appearing  In  requirements  languac.es  are 
stimulus-response  paths  In  RSL  ((Bell  £t  77],  [Alford  77],  [Davis  &  Vick 
77])  and  finite  state  machines  ([Henlnger  79],  [Davis  &  Rauscher  79]).  A 
finite  state  machine  Is  very  much  like  a  single  process — bettor  than  d.itaflow, 
perhaps,  but  permitting  no  explicit  parallelism,  decomposition  of  complexity, 
nor  modeling  of  the  environment. 

Stimulus-response  paths  (e.g.  Figure  7)  do  make  It  possible  to  decompose 
the  requirements  and  represent  parallelism.  The  "R-net"  in  Figure  7  shows 
explicit  parallelism  between  "STORE_FACTOR__DATA”  and  "EXA.MIN'i;_FACTORS" ,  and  is 
only  one  of  several  R-nets  specifying  the  entire  system.  Thev  do  not, 
however,  provide  for  representation  of  data,  the  Interaction  of  paths  via 
data,  or  Internal  synchronization  around  shared  data.  Because  the  process 
mechanism  integrates  data  and  processing,  It  is  a  more  complete  formalism,  and 
therefore  more  likely  to  be  able  to  cope  with  a  variety  of  systems  an.i; 
situations. 


Executablllt} 


In  the  operational  approach,  requirements  specifications  are  executable. 
This  means  that,  under  Interpretation,  the  specification  becomes  a  simulation 
model  generating  behaviors  of  the  specified  system. 

It  is  of  vital  importance  to  be  able  to  interpret  specifications 
regardless  of  their  level  of  abstraction.  Not  only  are  requirements  by  their 
nature  abstract  In  many  respects,  but  they  must  also  be  developed  bv 
successive  refinements  of  understanding,  each  version  of  which  should  benefit 
from  this  facility.  We  will  defer  until  3.4  a  discussion  of  how  this  can  he 
done,  and  only  deal  here  with  the  advantages  of  doing  so. 


Executable  specifications  can  be  tested.  As  mentioned  in  1.2,  this  me.ins 
that  they  can  be  debugged  by  the  analysts  who  write  them,  and  then  validated 
by  orlglnators/users  in  demonstrations.  Note  that  this  capability  includes  a 
"fast  prototyping"  facility,  which  is  now  being  mentioned  by  many  authors  as  a 
valuable  engineering  tool  ((Conn  80]),  because  the  specification  can  bo 
developed  to  whatever  level  of  detail  is  appropriate  for  a  prototype  and  then 
made  available  for  use  by  a  small  community  via  the  Interpreter. 

The  ability  to  test  is  no  panacea,  as  must  be  obvious  from  the  literature 
on  program  testing — testing  cannot  demonstrate  the  absence  of  errors,  it  is 
not  always  easy  to  get  the  right  kind  of  output  from  a  test,  and  it  is 
difficult  to  draw  any  general  conclusions  about  a  program  on  the  basis  of 
tests.  And  with  embedded  system  specifications,  there  Is  the  additional 
complication  that  any  test  must  choose  one  of  many  relative-rate-dependent 
process  execution  sequences.  Nevertheless,  the  problems  inherent  in  testing 
programs  have  never  caused  us  to  give  up  testing  then,  and  it  seems  plausible 
that  requirements  testing,  once  established  in  common  practice,  would  seem 
likewise  indispensable. 

Furthermore,  an  executable  requirements  model  can  continue  to  be  useful 
after  the  requirements  phase.  The  environment  part  of  the  model  can  be  used 
as  a  test  bed  during  system  development,  which  will  be  particularly  valuable 
for  embedded  systems  because  of  the  aforementioned  difficulties  of  testing 
then  "in  the  field"  (in  fact,  it  is  almost  always  necessary  to  write  .in 
environment  simulator  for  exactly  this  purpose).  The  model  of  the  propos.'d 
system  can  be  used  to  generate  sample  behaviors  for  accept.ince  testing. 

It  is  also  possible  to  attach  performance  constraints  in  such  a  w.-iy  th.it 
they  can  be  simulated  along  with  the  functional  requirements,  and  this  is  done 
in  PAISLey.  Slmulaticn  can  then  be  used  to  predict  performance  where  it  is 
too  complex  to  determine  analytically.  This  type  of  simulation  is  an 
Important  feature  of  SREM,  the  integrated  set  of  tools  by  which  RSL  is 
supported. 

There  is  a  final,  critically  Important,  advantage  of  oxecut.ibi  1 1 1 v  that 
has  nothing  to  do  with  testing  or  simulation.  It  Is  that  the  demands  of 
executablllty  impose  a  coherence  and  discipline — because  the  parts  of  .a 
specification  must  "fit  together"  in  a  very  strong  sense--that  could  scarcely 
be  obtained  in  any  other  way.  If  an  executable  requirements  specification  Is 
shown  to  be  internally  consistent,  that  means  It  will  continue  to  generate 
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behaviors  without  ever  halting,  deadlocking,  or  going  Into  an  undefined  state. 
In  other  words.  It  Is  guaranteed  to  be  a  valid  specification  of  some  system 
Interacting  with  some  environment.  Clearly  this  Is  the  utmost  that  any 
formally  defined  notion  of  Internal  consistency  could  dii  for  um,  since 
deciding  whether  they  are  the  right  system  and  environment  Is  a  natter  of 
validation  by  the  origlnator/user,  or  verification  of  consistency  with 
externally  defined  axioms  of  correctness. 

3.4.  Specification  In  an  applicative  language 

Within  a  process,  computation  (l.c.  the  successor  function  of  the 
process)  is  specified  using  a  purely  applicative  language.  "Applicative"  (or 
"functional")  languages  are  those  based  on  side-effect-free  evaluation  of 
expressions  formed  from  constants,  formal  parameters,  functions,  and 
functional  operators  ("combining  forms"  for  functions,  such  as  composition). 
Well-known  examples  of  applicative  languages  are  the  lambda  calculus,  pure 
LISP,  and  the  functional  programming  systems  of  [Backus  78]. 

3.4.1.  Advantages  of  applicative  languages 

Applicative  languages  are  currently  receiving  a  great  deal  of  favorable 
attention  because  of  their  numerous  theoretical  and  practical  advantages 
([Backus  78],  [Iverson  80],  [Smollar  80),  [Friedman  &  Wise  77',  [Friedrun 
Wise  78a],  [Friedman  &  Wise  78b],  [Friedman  Sr  Wise  79],  [Friedman  ft  Wise  80], 
among  others),  most  of  which  can  be  exploited  In  requirement;  specifications. 
To  begin  with,  because  applicative  languages  are  Interpretahie ,  thev  support 
the  executablllty  property:  processes  are  executed  by  repeatedly  replacing 
their  current  states  by  successor  states,  and  successor  states  are  discovered 
by  interpreting  the  applicative  expressions  which  define  them. 

For  purposes  of  high-level  specification,  the  most  Important  property  of 
applicative  languages  Is  their  tremendous  powers  of  abstraction,  l.e.  of 
decision  deferment.  Consider,  for  Instance,  the  functional  expression 
( (glV-l  »h(  2] ) ) "  ,  which  says  that  the  function  "g"  Is  to  be  applied  to  the 
argument  "y"  and  "h“  Is  to  be  applied  to  "z"  (the  "(  |"  s;Tibols  denote 
function  application  or  composition),  and  then  "f"  Is  to  he  applied  to  their 
values  (the  "(  )"  symbols  are  used  to  construct  tuples  of  data).  R\il  It  does 
not  constrain  the  data,  control,  processor,  or  other  resource  structures  used 
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to  do  BO.  Are  "g(y)“  and  "h(z]"  evaluated  aetiuent la  1  ly  or  in  parallel?  In 
what  data  structures  are  their  values  stored?  Perhaps  the  argunents  "y  "  and 
“z"  are  even  shipped  off  to  special  "g"-  and  ■■h"-proce93ors ,  respectively,  at 
different  nodes  of  a  network! 

Furthermore,  a  primitive  function  has  several  interesting 
Interpretations,  all  of  which  enable  additional  decompositions  of  complexity. 
A  primitive  function  can  represent  a  set  of  deferred  decisions,  to  he  made 
later  by  defining  the  function  in  terms  of  simpler  primitives.  It  can  also 
represent  a  mapping  which  will  always  remain  nondeterminlstlc  from  the 
perspective  of  the  requirements  model,  because  it  depends  on  factors  outside 
the  scope  of  the  model.  For  Instance,  in  specifying  a  terminal  we  might 
declare  a  primitive  function 

think:  DISPLAY  — >  INPUT, 

where  "DISPLAY”  is  the  set  of  all  CRT  screen  images  and  "I"?!’!"  Is  the  sot  of 
all  input  lines,  Co  represent  Che  human  user's  thought  processes.  Finally,  In 
PAISLey  a  primitive  function  can  be  an  abstraction  for  an  asynchronous  process 
Interaction  (see  below).  Because  of  these  many  options,  applicative  languages 
have  been  used  successfully  to  describe  phenomena  ranging  in  level  if 
abstraction  from  digital  hardware  to  distributed  system  requirements 
((Fltzwater  &  Zave  77],  [Snoliar  79]). 

An  Interpreter  for  an  abstract  specification  language  makes  expedient  and 
non-functionally-slgnlf leant  decisions  abovit  such  natters  as  control  and  space 
allocation.  The  only  other  thing  needed  for  Interpretation  Is  some  sort  of 
inpleraentation  of  functions  and  sets  left  primitive  In  tlie  abstract 
specification.  This  can  be  done  in  many  ways,  perhaps  the  simplest  of  which 
Is:  (1)  any  evaluation  of  a  primitive  function  whose  range  is  not  primitive 
yields  either  a  randomly  chosen,  or  a  "smallest",  element  of  the  range;  (?) 
any  primitive  set  is  temporarily  defined  to  be  the  set  "KlLi.F.R",  whoso  only 
element  is  the  constant  "'null'"  (thus  any  evaluation  of  a  primitive  function 
whose  range  is  primitive  necessarily  yields  "'null'"),  "'null'"  Is  often  used 
as  a  place-holder  where  a  value  must  be  generated  but  no  sonant Ics  need  to 
carried.  Another  way  to  interpret  primitive  functions  Is  to  display  their 
arguments  at  a  terminal  and  ask  the  analyst  to  supply  a  value,  thereby 
creating  an  interactive  testing  system.  In  either  rase,  the  effect  is  to 
Simulate  the  decisions  which  have  been  made,  without  Interference  from  the 
decisions  that  haven't  been  made. 


Another  advantage  of  applicative  languages  is  that  they  are  extremely 
convenient  for  formal  manipulations  such  as  verification.  This  is  because  an 
expression  has  "referential  transparency",  l.e.  Its  only  semantic  property  Is 
its  value.  An  applicative  program  can  sometimes  be  proven  consistent  with  an 
axiomatic  specification  of  correctness,  for  example,  merely  by  algebraic 
substitution!  This  facility  is  one  of  the  major  subjects  of  [Backus  78]. 

One  advantage  of  applicative  languages  that  will  not  be  exploited  for 
specifications  of  embedded  systems  Is  that  as  programming  languages, 
applicative  languages  may  have  more  potential  for  efficient  Implementation 
than  procedural  ones.  Because  the  "von  Neumann  bottleneck"  of  accessing  and 
referring  to  memory  one  word  at  a  time  has  been  eluded  ([Backus  78]),  the 
field  Is  clear  for  high-powered  optimization  by  Interpreter  writers  and 
machine  designers.  The  work  of  Friedman  and  Wise  on  large-scale 
multiprocessing  ([Friedman  &  Wise  78a])  and  research  on  dataflow  computers  are 
both  efforts  In  this  direction;  neither  form  of  parallelism  requires  the 
knowledge  or  participation  of  the  programmer. 

Embedded  systems  do  not  profit  directly  because  they  may  have 
performance,  accessibility,  distribution,  etc.  requirements  which  can  only  be 
simulated  (but  never  realized)  by  an  interpreter  running  on  a  conventional 
shared  computer  system,  even  though  that  interpreter  night  provide  a 
convenient  and  efficient  implementation  for  other  types  of  system.  For 
embedded  systems,  Interpretahle  specifications  are  clearly  distinguishable 
from  implementations  by  their  performance  and  resource  properties,  iesplte 
functional  equivalence. 

3.4.2.  PAISLey  as  an  applicative  language 

PAISLey  is  not  a  purely  applicative  language  because  states  in  general, 
and  process  states  In  particular,  are  not  applicative  co..cepts.  System 
specifications  can  be  written  In  a  purely  applicative  notation,  as  in  [Smoliar 
79]  and  [Frledoian  &  Wise  79).  In  [Zave  80a)  It  Is  explained  that,  while.  m.\ny 
aspects  of  even  embedded  systems  can  be  specified  applicat i ve ly ,  the 
specification  of  most  performance  requirements,  real-time  interfaces  with  the 
environment,  and  certain  resource  requirements,  all  necessitate  the 
introduction  of  some  non-appllcatlve  structure  such  as  processes. 
Furthermore,  processes  may  offer  a  helpful  form  of  decomposition  of  c.onplexl  tv 
not  available  In  purely  applicative  languages  when  feedback  loops  are  present. 


This  will  be  particularly  Important  with  our  requirements  specifications  for 
embedded  systems.  In  which  representation  of  the  feedback  provided  by  the 
proposed  system  to  the  environment  Is  a  primary  objective. 

Since  PAISLey  is  a  blend  of  the  applicative  world  and  the  non-appl lea t t ve 
world  of  processes  and  states,  the  "sean"  must  be  a  smooth  one.  The  two 
worlds  meet  at  the  mechanism  for  interprocess  interaction,  which,  is 
necessitated  by  the  existence  of  processes,  but  designed  to  fit  smoothly  into 
the  applicative  framework.  Interactions  take  place  through  a  set  of  three 
primitives  called  "exchange  functions"  which  carry  out  the  side-effect  of 
asynchronous  interaction,  but  look  and  behave  locally  (Intraprocess)  exactly 
like  primitive  functions.  Exchange  functions  are  defined  and  explained  in 
5.3.  They  are  a  unique  mechanism  which  seems  to  fulfill  our  purposes  very 
well,  and  also  offer  an  interesting  new  perspective  on  asynchronous 
interaction  mechanisms  for  distributed  processes. 

Applicative  languages  have  a  reputation  for  unreadabl 1 1 ty ,  and  general 
unsuitability  for  large-scale  software  engineering,  in  some  circles.  Vo 
believe  that  this  reputation  is  due  to  typelessness  and  recursion,  neither  one 
of  which  is  present  in  PAISLey. 

Recursion  is  what  purely  applicative  languages  use  to  specify  repetitive 
computation,  and  is  analogous  to  looping  (iteration)  in  procedural  la-ngviagcs. 
Both  are  analogous  to  the  repetitive  application  of  a  .successor  function  to 
produce  successive  process  states,  which  is  how  unbovinded  repetition  Is 
specified  in  PAISLey. 

In  most  applicative  languages,  the  only  type  of  data  object  is  r'u'  'i--' 
or  sequence,  and  all  functions  are  applied  to  one  list  and  produce  one  list. 
Since  every  function  should  be  prepared  to  accept  argument  lists  of  any 
Internal  structure,  there  must  be  a  distinguished  "undefined"  value  produced 
whenever  the  Internal  structure  of  the  argument  is  unsulted  to  the  semantics 
of  the  function  (as  in  [Backus  78])--and  this  mismatch  must  first  be  detected! 
Multiple  arguments  to  or  values  from  functions  must  he  packaged  In  single 
lists,  yet  the  existence  of  this  substructure  (or  any  ocher  substructure,  for 
that  matter)  cannot  be  explicitly  acknowledged. 

Of  course,  deliberate  substructure  In  data  items  Is  ubiquitous,  and  it  1  .s 
common  practice  to  *  ..ument  It  with  the  use  of  data  tvpes.  Kuridicrnoro , 
typing  In  a  language  provides  a  tiseful  form  of  redundancy  which  Is  susceptible 
to  automated  checks  of  Internal  consistency. 


In  PAISLey  non-prlraltlve  sets  can  be  defined  using  set  union  ("A  U  H"), 
cross-product  ("A  x  B"),  enumeration  (“{  'true',  'false'  }"),  and 
parenthesization.  The  domain  and  range  sets  of  every  function,  primitive  or 
not,  must  be  declared  (although  a  function  need  not  have  arguments).  The 
domain  and  range  declarations  can  use  arbitrary  set  expressions.  Here  are 
three  example  declarations: 

f: - >  A  ; 

g:  B  X  C  - >  DUE; 

h:  S - >  T. 

When  a  function  is  applied  to  arguments,  their  types  must  be  consistent 
with  the  domain  declaration  of  the  function.  Consistency  can  be  defined  with 
the  assistance  of  type  conversion,  however,  so  that  the  composition  "h[g[f]]" 
Is  perfectly  legal  if  the  definitions: 

A  -  B  X  C  ; 

S  -  INTEGERS; 

D  -  {  0,  2,  4,  6,  8  }; 

E  -  {  1,  3,  5,  7,  9  } 

have  been  made.  This  notion  of  typing  provides  all  the  documentation  and 
redundancy  desirable  for  engineering  goals,  without  sacrificing  any  of  the 
flexibility  attributable  to  typelessness .  All  that  it  requires  is  the  ability 
to  compare  any  two  set  expressions  for  containment,  which  is  easily  done  giver. 
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4.  QUALMS  ABOUT  OPERATIONAL  REQUIREMENTS 

Despite  the  obvious  advantages  of  operational  requi  roro  nt  ,  one  cannot 
help  but  have  certain  reservations  about  the  idea.  In  this  section  we  exai-ine 
its  apparent  disadvantages. 

4.1.  Encroaching  on  design 

Aren't  operational  specifications  actually  design  specifications  rat'ner 
than  requirements  specifications?  This  question  is  often  prompted  by  tiie 
precision,  potential  for  detail,  and  executablll ty  of  operational 
specifications . 

Traditionally,  it  is  said  that  requirements  state  ^hat  Is  to  be  done,  and 
a  design  states  how  to  do  It  ([Ross  &  Schonan  77]).  In  other  words;  Properly, 
requirements  specify  the  functional  and  performance  properties  of  a  systcr., 
where  both  "functional"  and  performance  properties  arc.  characteristics  of  t.''.' 


system  as 

experienced 

by 

its  environment 

,  but 

the  functicnal 

expres sable 

in  terms 

of 

digital  logic. 

while 

the  perform, ir.ee 

concern  such  physical 

concepts  as  time  (see 

5.4). 

Design  he. tins 

resources  from  which  the  system  is  to  he  constructed  arc  1  ntrod.nced .  Ryiter, 
design  is  a  matter  of  managing  scarce  resources  to  :.icot  pe  rf  o  r.na.  nc  ■  goals. 

Adopting  this  definition  of  the  boundary  between  reqni  re;ie;'iC  ^  and 
a  requirements  specification  does  not  stray  Into  design  if  an:  or.ly  1;  it 
avoids  managing  resources,  either  explicitly  or  Implicitlv.  PAr'Ecy  enables 
the  requirements  analyst  to  do  this,  as  Illustrated  by  the  requirements  f^r 
the  process-control  system,  the  process  structure  of  which  is  siiown  in  Fl.ture 
3  (process  interactions  are  labeled  with  the  type  of  Information  tliat  is 
transferred ) . 

Here  the  environment  Is  specified  by  processes  simulating  thit  tlir’c 
machines,  the  line-printer,  and  the  human  operator.  (The  environment  relo.i.int 
to  requirements  analysis  may  extend  further  than  this.  Including,  for 
Instance,  the  people  who  use  the  reports  .ind  their  Intended  piirpenes , The 
"machine-monitor"  processes  tend  to  their  individual  maclilnes,  reading  the 
sensors  and  providing  immediate  local  feedback.  Those  processes  ^Iso  'ar-. 
data  along  to  the  "factory-monitor"  process,  wliich  keeiis  rraeV  ■> 
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conditions  and  alarms  the  ‘‘operator "  when  necessary-  All  monitoring  proces.ses 
send  selected  data  to  the  "database" ,  which  answers  qiieries  from  the 
"operator"  and  t he  "report-generator" . 

Note  that  no  resources  are  expllctly  represented  in  this 
specification — all  of  the  internal  processes  are  derived  directly  from  the 
various  system  functions.  We  will  now  argue  that  neither  the  process 
structure  nor  the  structures  Inside  processes  place  implicit  constraints  on 
resources • 

Nowhere  is  the  difference  between  requirements  and  design  more  apparent 
chan  in  the  requirements  principle  of  "sufficient  processes" — use  as  many 
processes  as  performance  analysis  and  functional  decomposition  suggest.  Tho 
machine  monitors  are  separate  from  each  other  because  each  must  synchronize 
itself  with  a  different  (asynchronous)  machine,  and  the  factory  monitor 
performs  a  different  function  altogether.  The  report  generator  is  a  separate 
process  from  the  database  because  the  database  has  real-time  response 
requirements  and  the  report  generator  does  not.  It  is  likely  that  in  the 
design  for  this  system,  all  of  these  processes  will  be  implemented  by 
time-multiplexing  a  single  physical  processor.  The  processor  will  be  a  scarce 
resource,  and  must  be  allocated  (perhaps  using  priority  interrupts)  so  that 
the  performance  requirements  on  all  processes  will  be  net.  Thus  partition 
into  processes  is  a  way  of  expressing  relationships  having  to  do  with 
functionality,  synchronization,  performance,  etc.,  and  not  resource 
allocation. 

Within  processes,  we  have  already  discussed  the  nonconstraining  nature  of 
applicative  expressions.  The  handling  of  states  is  likewise  nor.conmi ttal . 
Consider  the  "database"  process;  its  state  space  is  "DATABASE",  the  set  of  all 
possible  process-control  databases,  and  its  successor  function  is 
"database-cycle".  "Database-cycle"  processes  one  input,  be  it  a  data  upd.nte 
or  query,  and  produces  as  its  value  a  new  member  of  "DATABASE",  which  replaces 
Che  old  process  state  at  the  end  of  the  process  step. 

There  are  many  ways  to  update  a  database.  Two  of  the  obvious 
possibilities  are  to  modify  records  In  place,  or  to  create  an  entirely  new 
copy  and  Chen  over-write  the  old  one.  The  former  is  more  efficient  but  only 
works  well  for  relatively  static  data  structures;  the  latter  is  more  flexible 
but  expensive,  and  also  more  amenable  to  rell.ablllty  measures — the  old 
database  Is  not  destroyed  until  the  new  has  been  successfully  completed. 
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These  aiid  Intermediate  [>oss  tbi  1 1 1  los  ,  diffiTlne.  In  their  ri>source  allocation 
and  performance  characteristics,  are  equally  well  snbsuneil  by  tlie  abstract 
mechanism  of  state  replacement. 

This  view  of  requirements  is  elegant  and  satisfying,  but  it  is  not  the 
whole  story.  Pragmatically,  a  requirement  is  any  property  of  t'ne  proposed 
system  that  is  necessary  to  satisfy  the  originating  organization  of  the 
acceptability  of  the  system,  and  these  properties  nay  very  well  include 
decisions  about  resources.  Use  of  a  particular  computer  or  software  subsystem 
may  be  required  because  the  originating  organization  already  owns  it,  and 
management  insists  that  it  be  used.  There  may  even  he  a  requirement  that  the 
system  must  fit  Into  a  particular  amount  of  memory;  this  night  be  the  case, 
for  instance,  if  the  system  is  a  monitor  of  experimental  equipment,  and  shares 
facilities  with  other  experiments  on  a  satellite.  The  amount  of  remory  in  t!ie 
on-board  computer  allocated  to  each  experiment  is  an  administrative  decision 
which  must  be  made  (at  least  tentatively)  before  work,  on  developing  the 
individual  experiments  can  begin. 

The  reality  Is  that  a  system  develops  through  a  hierarchy  of  decisions, 
each  decision  constraining  those  helow  It  in  the  hierarchy.  No  system  t  . 
developed  in  a  political  or  economic  vacuum,  and  almost  no  system  performs  It.s 
function  without  interfacing  with  any  pre-existing  computer  system;  as  a 
result,  some  decisions  are  made  prematurely  or  nonoptimally  compared  to  some 
theoretical  decision  procedure  based  on  technical  grounds  alone.  Thus,  even 
though  resource  decisions  are  premature  at  the  requirements  Iwcl,  any 
requirements  language  which  is  unable  to  record  then  will  he  t<?rrlbly  fragile, 
performing  adequately  only  in  the  most  idealized  of  situations. 

PAISLey  can  record  resource  decisions  because  resource  strvictures  are 
like  any  other  structures  occurring  in  digital  systems.  They  can  definitely 
be  specified  if  there  is  a  general  model  of  digital  computation,  which  PAISI.ey 
offers.  Hardware  and  software  modules,  for  instance,  can  be  specified  as 
processes,  and  then  included  as  part  of  the  environment  of  the  proposed 
system.  This  is  a  great  strength  of  the  operational  approach'-tlv  promise  of 
no  unpleasant  surprises  when  new  applications  or  economic  contexts  mre 
encountered . 

The  ultimate  test  of  whether  or  not  a  decision  belongs  In  the 
requirements  is  whether  or  not  the  system  could  feasibly  b.'  - nns true c oj  in  anv 
other  way.  This  criterion  can  be  Illustrated  by  several  feat.vires  of  tlu'  ii'.'KT 


system. 

The  first  requirements  problem  is  that  the  system  is  required  to  use  a 
military  standard  radio  link  for  communication  between  the  test  elements  and 
the  contractor-supplied  part  of  the  communication  network.***  This  is  a 
classic  example  of  a  (premature)  resource  requirement,  since  the  requirements 
should  confine  themselves  to  the  necessity  of  (and  performance  constraints  on) 
communication,  and  let  the  contractors  determine  the  best  method.  But 
accepting  the  Inevitable,  we  specify  the  existing  radio  link  as  part  of  the 
environment  of  the  proposed  system  (Figure  9). 

The  next  problem  concerns  the  times  to  which  event  messages  from  test 
elements  (new  positions  and  weapons  firings)  refer.  The  central  system  must 
know  these  quite  accurately  to  do  meaningful  simulation,  but  it  cannot  infer 
the  times  at  which  they  were  sent  from  the  times  at  which  they  are  received, 
because  delay  in  the  ground  communication  network  is  sure  to  be  long  and 
erratic. 

There  seems  to  be  only  one  solution  to  this  problem:  put  timestamps  on 
the  messages  when  they  arrive  at  the  radio  towers  (until  that  point  the  delay 
is  small  and  stable,  due  to  the  dedicated  radio  channels).  If  true,  there  is 
nothing  wrong  with  specifying  even  this  very  deslgn-llke  decision  in  the 
requirements  (Figure  10). 

Note,  however,  that  this  operational  requirements  specification  is  still 
quite  different  from  a  design  for  the  system.  The  specification  of  the 
"radio-tower"  processes  will  show  that  they  all  get  current  times  by 
requesting  them  from  the  "real- time-clock"  process,  which  "ticks"  once  per 
process  step.  The  asynchronous  interaction  point  within  the  radio  towers  will 
at  first  appear  as  the  primitive  function: 

current-time:  - >  TIME. 

The  necessary  performance  requirement  will  be  specified  as: 

current-time:  "time  - >  maximum  Is  1  mlcrosec". 

This  means  that  "current-time”  must  be  evaluated,  by  interacting  with  a  global 
clock,  In  one  microsecond  or  less  In  all  radio  towers.  The  design  to  meet 
this  requirement  will  probably  Involve  accurate  local  clocks  which  are 
synchronized  via  some  protocol  before  each  test  begins. 


Finally , 

we 

must 

consider 

exactly 

what  Is 

meant  by 

"real-t ime 

simulation" . 

Is 

the 

simulation 

event- 

oriented? 

Is 

each  incoming  message 

processed  as 

it 

arrives?  What 

If  a 

late-arriving 

message 

contradict  s 

cnnNthlnK  that  haa  already  heen  i-owpiirml?  (The  latter  could  happen  If,  In  the 
absence  of  a  recent  position  mrsnap.p,  l  ho  svslem  axl  rapo  la  l  ml  i  in*  cm  n-ui 
trajectory  of  a  test  element;  the  late-arrlvlng  message  could  show  that  It  had 
swerved. ) 

With  existing  levels  of  technology.  It  Is  not  feasible  to  build  a  system 
which  performs  simulation  of  this  complexity,  In  anything  close  to  real  time, 
and  backtracks  on  the  basis  of  belated  evidence.  Therefore  it  is  not 
over-constraining  any  feasible  design  to  put  a  "no-backtracking"  policy  into 
the  requirements.  Also,  the  simulation  must  be  oriented  toard  slices  of  time 
rather  than  events  because  a  shell  In  flight  presents  a  continuous  threat  over 
some  period  of  time.  The  discipline  Imposed  by  the  operational  approach 
forces  us  to  understand  these  Issues  before  specifying  the  requirements  for 
the  central  simulation  facility,  which  is  done  as  follows. 

The  relationship  between  simulation  time  and  real  time  is  shown  in  Figure 
11.  The  test  is  viewed  as  a  sequence  of  "frames",  or  snapshots,  each 
containing  the  positions  of  all  active  test  elements.  The  "granularity"  g  of 
the  simulation  Is  the  interval  between  frames.  The  granularity  must  be  at 
least  as  long  as  the  time  It  takes  to  compute  a  frame,  or  the  simulator  will 
fall  Increasingly  far  behind. 

Let  d  be  the  projected  maximum  delay  in  the  communication  network.  Then 
computed  frames  can  be  produced  with  a  steady  real-time  delay  of  d  g.  In 
computing  the  frame  for  time  t,  the  simulator  waits  until  t  +  d  to  make  sure 
it  has  received  all  messages  sent  at  t  or  before  (messages  arriving  later  th.in 
this  will  have  to  be  ignored),  then  computes  the  frame  to  bo  ro.xdy  at  t  ■»-  - 
g.  The  quantities  d  and  g  will  be  incorporated  into  performance  requirements, 
of  course. 

This  Is  carried  out  by  the  process  structure  shown  in  Figure  12.  The 
simulation  is  clocked  by  the  "Input-buffer"  process,  which  collects  messages 
continually  but  hands  them  over  to  the  simulator  in  hatches  at  intervals  of  . 
Each  step  of  the  "simulator"  process  computes  a  new  frame  from  the  old  frame, 
a  batch  of  messages,  and  various  threat  and  target  models.  It  also  produces  a 
batch  ■  of  "kill"  messages,  which  are  transmitted  by  the  "output-buffer" 
process . 

4.2.  Too  much  precision 

There  can  be  little  question  that  specifications  written  In  PMSLey  are 
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too  precise,  and  based  on  too  many  technical  principles,  for  cvistoners,  ciul 
users,  managers,  and  other  untrained  personnel  to  understand. 

At  the  same  time,  their  rigor  can  be  Invaluable  to  the  trained  analysts 
who  will  write  them  (this  Is  based  on  numerous  experiences  of  hjing  confronted 
by  surprise  with  the  vagueness  of  my  own  Ideas  about  a  system).  InforMl 
analysis  must  always  come  first,  but  we  have  not  yet  fully  exploited  the 
potential  of  formal  languages  for  expressing  approximate  or  incomplete 
knowledge  and  real-world  concepts. 

There  Is  not  really  a  conflict  here,  simply  because  nontechnical  people 
do  not  have  to  use  the  same  representations  that  the  analysts  do.  Analysts 
can  communicate  with  them  using  diagrams,  simplifications,  narrow  views, 
partitions  and  projections,  etc.  derived  from  the  current  PAISLey 
specification.  The  process  diagrams  (Figures  4,8,9,10,11)  are  nicely  vlsu.il 
and  seem  fairly  Intuitive,  for  Instance;  it  is  also  likely  that  dataflow 
diagrams  could  be  used  to  show  major  computations  without  bothering  about 
timing  and  control,  and  that  semantic  nets,  which  are  used  in  (Mittermeir  PCI 
and  (Yeh  &  Mlttermelr  80]  to  represent  data  structures,  could  be  used  for  the 
same  purpose  here. 

Among  the  most  popular  and  successful  features  of  SREM  (RSL)  and  PSL/FSA 
Is  that  specifications  are  stored  in  a  database  from  which  a  variety  of 
up-to-date  report.s  can  be  generated  automatically.  Wc  envision  PAI^Ley's 
being  installed  in  such  a  database,  and  hope  that  user-oriented  reports  and 
diagrams  could  likewise  be  produced  by  tools  running  on  the  current 
specification. 

4.3.  Interface  with  data-oriented  specification  techniques 

Other  researchers  have  investigated  the  problem  of  requirements  for 
data-processlng  systems,  using  as  a  starting  point  for  their  formalisms 
database  languages,  l.e.  languages  originally  developed  to  describe  thn 
"conceptual  schemas”  (abstract,  virtual,  semantic  structures)  of  d.it.sb.isos . 
The  notion  that  a  requirements  model  should  be  an  explicit  represent  itlon  I’f 
the  proposed  system  Interacting  with  Its  environment  has  also  been  derived  in 
this  context,  but  with  a  completely  different  type  of  specification  for  the 
model.  A  philosophy  of  data-oriented  modeling  is  presented  in  [Bal/.er  f. 
Goldman  79],  while  [Yeh  a_l.  79b],  [Roussopoulos  79],  and  i  Ml  c  t •'rmo  1  r  80  ', 
exemplify  It.  [Smith  A  Smith  79]  defines  a  partlcvilar  data-oriented 


specification  language  designed  to  have  all  the  generality,  flexibility,  and 
power  needed  for  complete  specification  of  systems  from  a  data-driven 
perspective. 

It  is  clear  that  a  data-oriented  technique  Is  a  more  natural  way  than 
using  PAISLey  to  develop  requirements  for  data-processing  systems.  Yet  data 
is  a  vital  part  of  any  system,  and  cannot  be  Ignored  by  any  reaui recent s 
technique.  It  is  our  purpose  here  to  show  that  process-oriented  PAISLey 
specifications  and  data-oriented  specifications  are  both  based  on  the 
underlying  model  shown  In  Figure  13,  and  can  potentially  be  compatible  and 
even  complementary.  Then  analysts  will  be  free  to  use  either  or  both  (in 
parallel)  as  the  application  and  phase  of  development  suggest. 

In  both  approaches  there  are  data  items  which  reflect  the  state  of  the 
relevant  part  of  the  environment  and  the  state  of  the  system.  The  basic 
relationships  among  data  items  are  even  the  same:  In  data-oriented  languages 
data  items  are  organized  into  types,  and  types  are  related  by  "generalization” 
(a  type/subtype  hierarchy)  or  ‘'aggregation"  (a  "coraponent-of "  hierarchy).  In 
PAISLey  set  membership  provides  typing,  set  union  provides  generalization,  and 
cross-product  provides  aggregation. 

Thus  if  the  collection  of  process  states  in  a  PAISLey  specification  is 
viewed  as  a  database,  it  differs  from  a  "normal"  database  only  In  having  a 
somewhat  restricted  structure.  Furthermore,  the  restrictions  are  tailored  to 
the  nature  and  needs  of  embedded  systems.  Specifically:  (1)  its  size  is 
fixed,  (2)  it  is  divided  Into  a  fixed  vector  of  components  (process  states), 
and  (3)  no  item  is  a  component  of  more  than  one  Item. 

Restrictions  (2)  and  (3)  come  about  because  the  specification  is  to  be 
interpreted  as  a  vector  of  autonomous  distributed  parallel  computations  (the 
latter  prevents  one  item's  being  shared  between  process  states).  Restriction 
(1)  is  based  on  the  philosophy  of  PAISLey  (see  5.1),  but  its  acceptability 
reflects  the  nature  of  embedded  systems — because  of  the  close  Interaction 
between  an  embedded  system  and  its  environment,  the  environment  Is  stable 
rather  than  transient.  Consider,  for  example,  the  processes  representing  test 
elements  in  the  environment  of  the  AFWET  system.  Presumably  a  large  and 
open-ended  set  of  planes,  tanks,  ships,  etc.  might  eventually  be  used  in 
tests,  which  would  Indicate  a  large  and  open-ended  !.et  of  environment 
processes.  But  the  requirements  document  puts  a  definite  limit  of  2h  on  the 
number  of  teat  elements  active  at  any  one  time,  and  Implies  that  each  is  to 
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have  a  dedicated  radio  channel.  It  makes  much  more  sense  to  construct  the 
model  with  26  test-element  processes  "hard-wired"  to  their  channels,  and 
consider  the  assignment  of  test-element  processes  to  physical  test  elements  to 
be  outside  the  scope  of  the  system. 

A  nice  example  of  the  contrast  between  data-processing  and  embedded 
systems  is  afforded  by  an  airline  reservation  system,  which  has  aspects  of 
both.  In  the  requirements  model  to  be  used  in  Section  5,  the  environment  of 
an  airline  reservation  system  consists  of  nothing  but  processes  representing 
terminals,  of  which  there  are  a  fixed  number.  Terminals  are  the  only  parts  of 
the  environment  that  are  relevant  to  this  communication-  and 
synchronization-oriented  PAISLey  specification.  The  data-oriented 
requirements  model  in  [Yeh  ^  al.  79a],  on  the  other  hand,  interprets  the 
environment  of  an  airline  reservation  system  to  consist  of  entities  such  as 
airplanes,  passengers,  flights,  and  reservations,  because  these  are  the 
environment  entitles  reflected  in  the  contents  of  the  system's  database.  Kote 
that  a  fixed  size  would  not  be  appropriate  here. 

To  return  to  Figure  13,  in  models  from  both  approaches  there  must  be 
computations  which  update  states  and  Interact  with  (or  cause)  other 
computations.  Hera  the  situation  is  one  of  complementarity  rather  than 
compatibility.  Database  languages  specify  data  updates  and  retrievals, 
sometimes  informally,  but  usually  with  a  syntax  based  on  the  predicate 
calculus.  They  do  not  specify  explicit  concurrency,  communication,  or 
control.  PAISLey,  on  the  other  hand,  lends  Itself  to  specifications  in  which 
data  manipulations  are  left  primitive  (although  the  work  in  [Frankel  79]  may 
lead  directly  to  a  marriage  of  functional  and  database  concepts).  We  are 
optimistic  about  the  possibility  of  defining  an  interface  between  the  two 
types  of  specification  so  that  decisions  made  in  one  could  be  translated  into 
the  other. 
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5.  THF,  PAISLF.Y  l.ANOUACK 

In  this  section  full  details  of  PAISLcy  are  presented,  including  a  new 
mechanism  for  process  Interactions,  and  sped f ication  of  performance 
requirements.  An  LALR  grammar  for  PAISLey  in  BNF  form  can  be  found  in  the 
Appendix. 

5.1.  Language  philosophy 

PAISLey  Is  Intended  to  be  simple.  In  particular,  only  features  which  are 
directly  associated  with  run-time  semantics  are  included. 

For  production  purposes  the  language  must  be  supported  by  a  system  which. 
In  addition  to  storing  specification  fragments  and  collecting  them  into 
executable  configurations  (not  to  mention  providing  tools  for  static  analysis 
and  report  generation),  offers  such  conveniences  as  scopes,  versions,  macros, 
parameters,  libraries,  meta-notations,  etc.  The  current  frenzy  of  research  on 
"programming  environments"  makes  It  plain  that  the  design  of  such  a-.-, 
environment  is  not  a  trivial  task,  and  should  probably  not  be  undertaken 
simultaneously  with  development  of  the  specification  semantics. 
Specifications  prepared  using  any  of  the  above  features  would  be  translated 
into  PAISLey  (as  currently  defined)  before  interpretation. 

Stylistically,  PAISLey  follows  APL  in  using  distinct  symbols  for  distinct 
operators  (but  has  far  fewer  of  them!).  This  leads  to  a  concise  notation  in 
which  essentially  all  words  are  user-chosen  mnemonics.  In  this  decision  and 
the  one  above,  we  apply  exactly  the  same  philosophy  as  (Hoare  73]. 

One  other  Important  principle  is  that  every  operational  structure  must  he 
realizable  with  a  bounded  amount  of  resources  (time  and  space).  There  is  a 
bounded  number  of  processes,  no  process  state  can  require  an  unbounded  anouiu 
of  storage,  and  no  process  step  can  require  an  unbounded  amount  of  evalvintlon 
time . 

The  purpose  of  this  Is  performance,  l.e.  making  it  possible  to  design 
systems  which  are  guaranteed  to  meet  their  performance  requirements.  Clearly 
If  s  computational  path  contains  an  unbounded  loop,  or  may  have  to  construct  a 
data  structure  of  unbounded  size,  no  guarantee  that  It  meets  an  absolute  time 
constraint  is  possible.  In  PAISLey  the  only  unbounded  "structure"  is  the 


Infinite  succession  of  process  steps  of  each  process,  and  this  one  exception 
cannot  be  avoided. 

The  static  system  structures  which  result  from  the  boundedness  principle 
will  greatly  facilitate  proofs  of  Internal  consistency,  correctness,  and  other 
formal  properties. 

5.2.  Sets,  functions ,  processes ,  and  systems 

Statements  in  PAISLey  are  delimited  by  semicolons,  and  comments  are 
enclosed  In  double  quotation  marks. 

Names  are  typed  for  greater  readability.  The  names  of  functions  are 
always  In  lower-case  letters,  and  the  names  of  sets  are  always  In  upper-case 
letters  (hyphens  and  Integers  may  be  used  In  either,  but  they  mus  begin  with 
alphabetic  strings).  Constants  are  either  numbers,  or  strings  enclosed  in 
single  quotation  marks. 

There  are  four  kinds  of  statement;  system  declarations,  function 
declarations,  set  definitions,  and  function  definitions.  Since  a  system  Is  a 
fixed****  tuple  of  processes,  we  use  the  tuple-construction  notation  for  a 
system  declaration.  A  process  is  declared  using  a  function  application  which 
applies  Its  successor  function  to  an  expression  evaluating  to  its  initial 
process  state.  Thus  a  system  consisting  of  four  processes,  three  being 
terminals  and  the  fourth  being  a  shared  d.itabase,  would  be  declared  as: 

( terminal -1-cycle [blank-display] , 
termlna 1-2-cycle  blank-display  , 
terminal-3-cycle [blank-display j . 
database-cycle[ Initial-database] 

). 

where  the  following  domain-range  declarations  would  be  appropriate: 

terminal-l-cycle:  DISPLAY  - >  DISPLAY; 

blank-display:  - >  DISPUY; 

database-cycle:  DATABASE  - >  DATABASE; 

Initial-database:  - >  DATABASE. 

Terminal  processes  have  the  contents  of  the  current  displays  as  th-lr  procc's 
states.  Note  that  there  Is  no  explicit  naming  of  processes  or  systems;  this 
would  undoubtedly  be  added  as  part  of  any  "envl ronnent  '  facilities. 

Function  declarations  give  properties  of  functions,  and  may  therefore  he 
redundant  for  nonprlmltlve  (defined)  functions — when  the  properties  are  a’.so 
deducible  from  the  function's  definition.  Declaratlrns  of  nonprlmltlve 
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functions  can  and  should  be  checked  for  consistency  with  their  doflnltlms. 
All  function  declaration  statements  begin  with  the  function  name  and  a  colon; 
what  follows  Is  either  a  domain-range  declaration,  of  which  we  have  seen  many, 
or  a  performance  property  (see  5.4). 

Set  definitions  define  set  names  In  terms  of  set  expressions,  which  use 
set  union,  cross-product  (which  has  precedence  over  union),  enumeration,  and 
parentheslzatlon  (all  shown  In  3.4.2).  Note  that  the  size  of  all  data 
structures  is  bounded,  because  all  tuples  (members  of  sets  defined  by 
cross-product)  have  a  bounded  number  of  components. 

Function  definitions  define  function  names  In  terms  of  function 
expressions,  and  may  use  formal  parameters,  even  structured  parameter  lists, 
to  do  so.  Here  are  some  possible  beginnings  for  function  definition 
statements: 

new-func-l  -  .  .  .  ; 
new-func-2[p]  -  .  .  .  ; 

new-func-3[ (p,q) ]  *  .  .  .  ; 
new-func-4{ (p, (q ,(r , s) ) ) ]  -  .  .  .  . 

Formal  parameters  have  the  same  syntax  as  function  names;  the  argument 
structure  must,  of  course,  agree  with  the  function's  domain  declaration. 

Function  expressions  may  use  function  names,  formal  parameters, 
constants,  applications  of  functions  to  arguments,  tuple  cons t rue t  Ion ,  and 
conditional  selection.  Conditional  selection  (like  the  l.ISP  "cond")  has  the 
syntax  ''/pl;fl,  p2:f2,  •  .  .  't  rue' :  f  n/ ” ,  and  evaluates  to  the  value  of  t'-.e 
first  functional  expression  "fl"  such  that  the  predicate  ( Boole.in-va  Ir.oc 
functional  expression)  "pi"  evaluates  to  "'true'".  Note  that  M'.ore  is  no 
unbounded  iteration,  such  as  would  be  provided  by  "while  .  .  •  fho  .  .  n^r 

Is  recursion  allowed.  Bounded  iteration  can  he  specified  using  conpos  i  1 1  on . 
The  result  is  that  the  number  of  primitive  operations  to  evaluate  any 
function.  Including  a  successor  function,  can  be  bounded  a  • 

As  a  simple  example,  consider  the  following  specification  of  tlie 
successor  function  of  a  process  representing  a  CRT  terminal: 
terminal -cycle:  DISPLAY  - >  DISPLAY; 

termlnal-cyclefd]  ■  display (display-and-trans act ( (d .think -of -re.; nest  f 1  j , 

thlnk-of-request :  - >  REQUF.ST; 

dlsplay-and- transact: 

DISPLAY  x  REQUEST  — ->  DISPLAY  x  (RESPONSE  U  EKROR-NESSACF ; 
display-and-transact ( (d , r) ]  ■  (dlsplayf (d ,r ) ] .trans.ict [ r ] ) ; 
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transact:  REQUEST  - >  RESPONSE  U  ERKOR-MESSAOE ; 

display:  DISPLAY  x  (REQUEST  U  RESPONSE  U  ERROR-MESS\CE ) - •>  DISPLAY. 

The  process  handles  one  transaction  per  process  step,  reflect  Inj^  hoth  the 
request  and  the  response  in  the  display.  The  prlnltlve  function  "display"  can 
carry  out  scrolling  or  whatever  other  formatting  is  desired. 

Even  aiming  for  a  minimum  of  conveniences,  It  is  impossible  to  do  without 
some  feature  for  defining  groups  of  nearly  identical  items.  In  PAISLey  this 
Is  done  at  all  levels  using  the  same  index  notation,  as  seen  in: 

VECTOR  -  /n..lO<  X  INTEGER  >, 

which  defines  members  of  Che  set  "VECTOR"  to  be  10-tuples  of  integers.  Index 
notation  always  denotes  a  sequence  of  the  expression  In  angle-brackets,  with 
Che  first  symbol  in  the  brackets  used  as  the  sequence  delimiter.  The  integers 
after  the  "ll"  give  Che  lower  and  upper  bounds  of  the  sequencing  count.  The 
only  Index  notation  without  a  delimiter  symbol  is  the  one  for  bounded 
functional  composition  (application),  which  makes  "i'l  ..3  <  func  >  [argj" 

equivalent  to  "f unc [ func [ func (arg ]])" . 

In  most  cases  what  we  want  is  a  group  of  statements  or  expressions  which 
differ  slightly.  This  Is  done  by  operating  on  names,  which  are  defined  so 
that  "syllables"  (alphabetic  substrings  delimited  by  hyphens)  are  seraanticaHy 
meaningful.  If  the  header  for  an  index  notation  begins  with  a  "syllable" 
before  the  "/I",  any  syllable  matching  It  In  a  name  in  the  repeated  expression 
will  be  replaced  by  successive  Integers  from  the  lower  bound  to  the  upper 
bound.  Thus: 

BIG-SET  •  J01..3<  U  LITTLE-SET-J  > 

Is  equivalent  to: 

BIG-SET  -  LITTLE-SET-1  U  LITTLE-SET-2  II  LITTLE-5ET-3 , 
and  Che  system  declaration: 

(k//0.  .9999<,termlnal-k-cycle (blank-display ] >. 
database-cycle ( Initial-database  I 

) 

creates  a  system  with  10,000  terminal  processes  (an  airline  reservation 
system!),  where  the  successor  function  of  tlie  thlrti'enth  one  Is 
''tennlnal-12-cycle" . 

Index  notation  can  even  extend  over  groups  of  statements.  Suppose  we 
want  our  10,000  terminals  to  be  Identical,  except  that  some  1  dent  I f lea r i on 
must  be  built  Into  "transact",  the  primitive  function  whose  elaboration  will 
send  to  and  receive  from  the  central  system.  This  can  he  done  hv  maklnc 


slight  modlficaclonR  Co  the  terminal  sperl f Icatlon  already  ylv'en,  as  follows: 

k//0..9999 

<  ;  termlnal-k-cycle:  DISPUY - >  PISI’LAY; 

Cennlaal-k-cycle[d]  • 

dlsplay-and-transact [ (d ,r ) ]  *  (display [ (d , r )], k-transact [ r ]) ; 

k-transact:  RESPONSE  - >  RESPONSE  U  ERROR-MESSAGE; 

5.3.  Asynchronous  Interactions 

5.3.1.  Definition  of  exchange  functions 

Asynchronous  interactions  between  processes  are  specified  using  tiiree 
primitive  functions  known  collectively  as  "exchange  functions".  An  exchange 
function  carries  out  two-way  point-to-point  mutually  synchronized 
communication.  It  has  one  argument,  which  provides  a  value  to  be  output,  and 
always  returns  a  value  which  was  obtained  as  input.  Thus  within  the  process 
an  exchange  function  looks  like  any  other  primitive  function;  it  has,  however, 
tne  side-effect  of  carrying  out  a  process  interaction.  By  making  interaction 
primitives  masquerade  as  functions,  we  achieve  compatibility  with  applicative 
notat ion. 

An  exchange  function  whose  evaluation  has  been  initiated  interacts  hv 
"matching"  (to  be  explained)  with  another  pending  exchange  function.  The  twi 
exchange  arguments  and  terminate,  so  that  each  returns  as  its  value  the 
argument  of  the  other. 

Each  exchange  function  has  two  attributes  to  be  specified,  namely  a  type 
("x",  "xm”,  or  "xr")  and  a  channel  (a  user-chosen  identifier  which  has  the 
syntax  of  a  function  name).  The  exchange  function  with  type  and  ch.innel 

"chan"  is  named  "x-chan",  the  exchange  function  with  tvpe  "xr"  iiui  channel 
"real-time"  is  named  "xr-real-t Irae" ,  etc.  Only  exchange  functions  with  : he 
sane  channel  can  match  with  each  other. 

The  "x"  is  the  basic  type  of  exchange  function.  It  can  match  wltli  .inv 
other  pending  exchange  function  In  its  class.  Including  another  of  tvpe  "x". 
If  no  other  exchange  Is  pending,  it  will  wait  until  .me  Is.  If  there  are 
several  pending  match  possibilities,  a  match  will  he  chosen 

\  a 


nondetermlnistlcally ,  with  the  proviso  chat  there  iruis 


ho  no  lockout 
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situation  where  a  penHlng  exchange  waits  indefinitely  while  Its  natch, 
opportunities  are  given  to  other,  more  recently  evaluated,  exchange 
functions) • 

CoQpetitive  situations  occur  In  most  systems.  To  enable  succinct 
specification  of  them  we  have  exchange.?  of  type  "xm",  which  behave  exactly 
like  ''x'"s  except  that  two  "xiii'"s  In  the  same  class  cannot  match  with  each 
other.  They  can  then  compete  to  match  with  an  exchange  of  some  other  type,  as 
the  examples  will  show. 

Embedded  systems  typically  have  real-time  interfaces,  especially  with  the 
processes  In  their  environments.  To  specify  these  we  need  a  third  type  of 
exchange  function,  the  "xr",  which  behaves  like  the  others  except  that  it  will 
not  wait  to  find  a  match.  If  evaluation  of  an  "xr"  is  initiated  and  there  is 
no  other  pending  exchange  in  its  class,  the  "xr"  terminates  i.i)medlately 
without  matching,  returning  its  own  argument  as  its  value.  It  is  always 
possible  to  determine  whether  or  not  an  "xr"  matched  by  giving  it  an  argument 
distinct  from  any  chat  it  could  obtain  by  exchanging. 

Figure  14(a)  shows  the  possible  matches  of  exchange  types  within  a  class. 
Figure  14(b)  (from  [Friedman  &  Fllman  80])  shows  the  derivation  of  the  three 
types.  There  must  be  both  fully  synchronized  primitives  ('synchronizing”!, 
and  also  those  which  do  not  synchronize  themselves  ("free-running").  There 
must  be  exchanges  which  can  match  with  their  own  kind,  and  those  that  compete 
with  their  own  kind.  This  makes  four  possibilities,  except  that  a 
free-running  type  which  exchanges  with  its  own  kind  woul.i  bo  impossible, 
because  it  would  require  "matching"  two  slroultaneou.s ,  i  ns  tant  aneou.s  events. 

5.3.2.  Examples  of  fully  synchronized  Interactions 

In  this  section  we  will  use  exchange  functions  to  specify  t'.'.o 
interactions  between  transaction-processing  terminals  and  ttio  central 
database.  "Transact"  in  the  terminal  specification  is  elaborated  as  follows: 

transact [r]  * 

recelve-response ( s end-request ( r I J ; 

send-request:  REQUEST - >  FILLF.R; 

send-request ( r )  ■  xm-requ[r]; 

receive-response:  FILLER  - >  RESPONSE  U  ERROR-MESSAGE; 

recelve-response ( 'null' I  •  x-resp[ 'null' ] , 
and  the  database  process  successor  function  Is  specified  ,is: 


database-cycle [d  ]  « 

f  Inallze-t  ransact  lon[  per  forra-t  rans.ict  ton  [(d.recelve-requesi;);  ]  ; 

recelve-request :  - >  REQUEST; 

recelve-request  -  x-requ[ 'null' ] ; 

perform-transactlon:  DATABASE  x  REQUEST  - >  DATABASE  x  RESPONSE; 

f Inallze-transaction:  DATABASE  x  RESPONSE  - >  DATABASE; 

f Inalize-c ransaction [ (d , r ) ]  »  pro J-2-1 ( (d , send-response [ r  ] )  ]  ; 

send-response:  RESPONSE  - >  FILLER; 

send-response [ r ]  “  x-resp[r]. 

By  renaming  (redefining)  the  exchange  functions  with  mnemonic  names,  we  are 
also  able  to  type  their  domains  and  ranges.  Exchange  functions  themselves  are 
typeless  because  they  must  handle  all  types. 

"Send-request"  In  a  terminal  and  "recelve-request"  in  Che  database  match 
with  each  other  to  transmit  the  request.  Note  chat  the  type  "xn"'s  in  the 
terminal  compete  for  the  type  "x"  In  the  database;  if  nothing  but  "x"'s  were 
used,  two  evaluations  of  "send-request"  might  match  with  each  other!  Since 
the  "xm"  and  "x"  are  symmetric  with  respect  to  synchronization,  either  -.ay 
have  to  wait  for  the  other. 

After  the  request  is  processed  against  the  databa.se, 
"f inallze-transaction"  disposes  of  the  results.  It  is  defined  in  terms  of  tb.e 
Intrinsic  function  ''proJ-2-1",  which  projects  an  ordered  pair  onto  Ic.s  flr-st 
component,  In  this  case  the  updated  database.  The  second  cc.aponent  i--- 
evaluated  only  for  its  side-effect  of  sending  the  respon.se  bac'--..  .and  t':'e 
"'null'”  value  it  returns  is  thrown  away. 

"Receive-response"  could  have  been  defined  using  type  "xm”,  bvit  an  "x”  is 
also  correct,  because  precedence  constraints  enforced  by  ti-.e  functi.vial 
nesting  of  "send-request”  inside  "receive-response"  ensure  tliat  at  most  one 
Instance  of  "receive-response"  will  be  in  evaluation  at  any  one  time,  na.aelv 
that  of  t'  e  piv^,.e93  whose  request  Is  now  being  processed.  Thus  matching  in 
the  class  "resp"  is  always  unique. 

5.3.3.  Examples  of  free-running  interactions 

A  "free-running"  process  Is  one  whose  only  Interactions  ncoir  via  "xr", 
so  that  It  will  never  wait  to  synchronize  with  another  process.  The 
prototypical  free-running  process  Is  a  real-time  dork,  whi-h  ticks"  om'e  per 
process  step,  and  could  not  fulfill  its  Intended  function  1,'  it  had  anv 


synchronizing  Interactions.  Such  a  process  Is  -.peclfled; 

(clock-cycle [ 0] ,  .  .  .  );  • 

clock-cycle;  TIME  - >  TIME; 

clock-cycle[t]  -  pro j-2-1 ( (Increment ( t ] ,of fer-t Ime [ t ])] ; 

Increment:  TIME  - >  TIME; 

offer-time:  TIME  - >  FILLER  U  TIME; 

of fer-t Ime [ t ]  -  xr-tlme(t]. 

Any  process  wishing  to  read  the  current  time  must  evaluate: 

current-time:  - >  TIME; 

current-time  ■  xm-tlme [ 'null' ) . 

Concurrent  ''xm-tlme'"s  will  compete  to  match  with  "xr-tlme",  Inplying  for  this 
particular  specification  that  no  two  readers  will  ever  get  the  same  clock 
value . 

Another  common  type  of  free-running  process  Is  a  digital  simulation  of  a 
nondlgital,  unintelligent  environment  object.  Here  Is  the  top-level 
specification  of  the  processes  representing  the  machines  in  the  environment  of 
a  process-control  system  ((Zave  &  Yeh  81]); 

jn..3 

<  ;  machine- j-cycle:  MACHINE-STATE - >  MACH I  NT-STATE ; 

machine-j-cycle[m]  ■ 

proj-Z-l ( (slraulate-machlnef (n, f eedback- i-1 f-any ) ] , 
of fer-nachlne- j-data [ sense [m ] T 
)]; 

feedback-j-if-any;  - >  FEEDBACK  U  FILLER; 

feedback- j-lf-any  -  xr- j-back[ 'null' ] ; 
s Imu 1 a  t  e-ma  chine: 

MACHINE-STATE  x  (FEEDBACK  U  FILLER)  - >  MACHINT-STATE ; 

sense:  MACHINE-STATE  - >  SENSOR-DATA; 

offer-machlne-J-data:  SENSOR-DATA  - >  FILLER  H  SENSOR-DATA; 

offer-machine-J-data[s ]  •  xr-J-sens(s] 

>. 

During  each  process  step  two  things  are  done  In  parallel:  (,  1 ) 
"simulate-machine"  computes  the  next  process  state,  which  Is  an  element  of 
"MACHI^-STATE"  encoding  the  machine's  current  status,  and  (2)  the  current 
output  of  sensors  attached  to  the  machine  ( "sense (m j” )  is  offered  to  the 
control  system  via  "xr-J-sens".  If  the  control  system  Is  ready  to  accept  the 
data  from  this  machine  cycle  an  exchange  will  take  place;  otherwise  the  data 
will  be  gone  forever. 
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"Slmulatft-machlne"  has  two  arguments ;  the  current  machine  state,  and  the 
value  returned  by  " feedback- )-l f-any" .  This  function  is  defined  as 
"xr- j-back" ,  an  exchange  function  which  Interacts  with  sevorni  sites  In  the 
control  system  which  provide  controlling  feedback  to  the  Jth  machine.  If  some 
actuator  is  being  activated  at  the  moment  "xr-j-back"  Is  evaluated,  an 
exchange  takes  place  and  a  value  in  "FEEDBACK"  is  returned.  Otherwise  the 
argument  "'’null'"  is  returned,  Indicating  that  no  actuators  are  being  used. 

Our  final  example  of  a  free-running  process  is  a  producer-consumer 
buffer.  Its  process  state  is  the  current  buffer  contents,  and  is  successor 
function  is: 

next-buffer:  BUFFER  - >  BUFFER; 

next-buffer [b]  »  give-to-consumer[get-from-producer [b]  ) ; 

get-f rom-producer :  BUFFER  - >  BUFFER; 

get-from-producer[b]  -  /full[bl:  b, 

"true"  :  put-on-tall [ (xr-prod [ 'nul 1' ], b)  ] 

/  » 

give-to-consumer :  BUFFER  - >  BUFFER; 

give-to-consumer [b]  ■ 

/emptyfb]:  b, 

'true  :  put-on-head ( (rest (b) ,xr-cons [ f irst ( b) ]) ] 

I  • 

On  each  process  step  "get-f rom-producer"  provides  the  opportunity  to  put 
one  new  element  in  the  buffer  (assuming  it  is  not  already  full).  If  some 
producer  has  a  pending  "xm-prod[new-eleraent] " ,  "new-element"  will  be  returned 
as  the  value  of  "xr-prod"  and  Inserted.  Otherwise  "xr-prod"  returns  "'null'", 
which  "put-on-tail"  will  simply  ignore. 

Likewise,  on  each  process  step  "give-to-consumer"  offers  tne  element  at 
the  head  of  the  buffer  ("first(b)")  to  any  process  evaluating 

"xm-cons [ 'null' ] " •  If  such  an  evaluation  is  pending  an  exchange  will  cake 
place,  and  "xr-cons[f lrst(b] ]"  will  return  "'null'",  which  "put-on-head"  will 
Ignore.  Otherwise  the  unconsumed  "firstfbj"  will  be  returned,  and 
"put-on-head"  will  reinstate  it. 

The  expected  behavior  of  this  process  (at  least  under  light  loading)  will 
be  to  cycle  very  fast,  checking  for  interactions  but  not  having  any  on  most 
process  steps.  This  shows  that  exchange  functions  are  In  some  sense  more 
primitive  than  synchronization  mechanisms  which  enable  a  process  to  wait  for 
any  one  of  several  events  to  occur.  The  payoff  is  a  much  simpler 

implementation  for  exchange  functions,  and  the  choice  is  In  keeping  with  the 
PAISLey  philosophy  of  simplicity  and  minimal  semantics.  It  is  also  arguable' 


chat  Che  above  apeclf IcaCton  Is  as  perspicuous  as  any,  largely  because  of  the 
benefits  of  applicative  style. 

5.3. 4.  Ifflplemencation 

In  almost  all  cases  the  pattern  of  matches  within  a  class  is  one-to-one 
or  many-to-one,  the  latter  for  resource  competition.  In  this  section  we 
present  an  efficient  distributed  algorithm  for  implementing  exchange  ;.'.acching 
in  these  cases  (one  additional  condition:  it  cannot  be  raany-to-one  matching 
where  the  "xr"''s  are  the  "many").  In  all  cases  a  central  matcliing  facility 
for  each  class  will  do  the  Job. 

Consider  first  an  exchange  class  with  many  "xm"'s  and  one  "x"  (or  just 
two  "x''‘"s,  In  which  case  one  of  them  takes  the  role  of  the  "xm"  in  this 
description),  all  residing  at  different  nodes  of  a  network  (this  is 
Illustrated  In  Figure  15).  When  an  "xm"  is  initiated,  a  message  carrying  its 
argument  is  sent  to  the  node  where  the  matching  "x"  resides.  These  messages 
are  queued  up  In  arrival  order.  When  the  "x"  is  initiated,  if  the  queue  is 
empty,  it  waits  until  it  is  not.  When  the  queue  is  not  empty,  it  removes  the 
first  entry  as  the  "match",  takes  the  value  stored  there  as  its  own  value, 
sends  a  termination  message  containing  its  argument  to  the  matching  "xm",  and 
continues.  Computation  can  continue  at  the  "xm"  as  soon  as  the  termination 
message  (with  Its  value)  Is  received. 

This  implementation  uses  only  two  messages  per  match,  and  automatically 
prevents  lockout  with  FCFS  queueing.  For  classes  with  one  "xr"  and  either  one 
"x"  or  many  "xm"'s,  the  queue  Is  formed  at  the  site  of  the  "xr",  and  the  only 
modification  necessary  is  that  if  the  "xr"  is  initiated  when  the  queue  of 
possible  matches  is  empty,  then  it  does  not  go  into  the  wait  state. 

5.3.5.  Further  properties  and  justifications 

Because  exchange  functions  are  only  "pseudo-functions"  and  liave 
side-effects,  expressions  containing  them  cannot  be  optimlced  to  avoid 
evaluation  of  expressions  whose  values  are  not  needed.  The  most  common 
example  of  this  Is  a  successor  function  with  the  form  "proj-2-1 ( (a , b) ] " ,  where 
expression  "a"  computes  the  next  state  and  "b"  Interacts  with  other  processes. 

There  is  also  a  potential  problem  with  distributing  values  obtained  by 
interaction,  but  the  formal  parameter  mechanism  does  this  nicely.  Suppose  the 


effect  of 


/equalf (x-denora( 'nul I' ) ,0) 1 :  'dlvlde-chcck' , 

^'Cnie  :  divide  [  (numerator ,  x-d«.*nom(  'null'  ) )  J 

Is  wanted,  where  both  usages  of  the  value  returned  by  an  exchange  are  supposed 
to  result  from  a  single  evaluation.  This  can  be  specified  unambiguously  by 
defining  "quotient"  as: 

quotient f (n,d) 1  “  /equal [ (d ,0) ) ;  'divide-check', 

'true  :  divlde[ (n,d) ) 

/  » 

and  then  using  It  In  the  Invocation  "quotient [ (numerator , x-denon[ 'nu 1 1 '  j ) J " . 

Establishing  the  Internal  consistency  of  a  specification  with  exchange 
functions  requires  some  attention.  The  range  of  a  user-chosen  function 
defined  as  an  exchange  must  agree  with  the  domains  of  all  chose  with  which  it 
can  exchange.  Furthermore,  precedence  constraints  caused  by  nested  evaluation 
structures  can  cause  exchange  deadlocks.  But  the  channel  of  an  exchange 
function  has  been  made  a  constant  attribute  rather  than  an  argument  to  it  just 
so  Chat  exchange  patterns  would  yield  to  static  analysis,  and  simple  arguments 
do  establish  deadlock-freedom  In  many  common  cases.  For  instance,  the  process 
hierarchy  visible  in  Figure  8  expresses  the  acyclic  "dependency"  structure  of 
the  Interactions  In  the  system;  the  argument  that  this  prevents  deadlock  is  a 
common  one  In  the  operating  system  literature  (e.g.  [Brinch  Kansen  77]). 

There  are  so  many  proposals  for  distributed  interaction  mechanisms 
current  today  that  comparison  and  justification  are  essential.  Most  properly, 
exchange  functions  are  motivated  and  justified  by  our  goal  o'"  fictise 
processes  and  asynchronous  interactions  into  an  applicative  framework,  and  in 
this  role  they  are  almost  unique  (see  also  [Milne  &  Milner  79]).  Their 
generality  Is  established  by  Figure  14(b)  and  by  extensive  experience  with 
them,  which  Indicates  that  the  only  kind  of  Interaction  they  cannot  specify  is 
unbounded  broadcast. 

Exchange  functions  can  also  be  justified,  however,  on  the  same  basis  as 
procedure-based  mechanisms,  which  fall  Into  the  two  general  categories  of 
procedure-call  mechanisms  ((Brinch  Hansen  78],  (Hoare  74],  [Ichblah  e£  a_l_. 
79])  .and  message-passing  ( (Rao  80)).  Exchange  functions  are  more  primitive 
than  procedure  calls  because  they  only  specify  interaction  at  one  pi^int  in 
time  rather  than  two  (procedure  call  and  return).  They  are  thus  more  general 
and  easier  to  Implement,  while  the  mutiial  synchronization  of  the  conmunicat ing 
processes  provides  much  of  the  structure  .and  control  usiially  associated  with 


procedure-call  mechanisms. 

It  Is  the  mutual  synchronization  that  most  distinguishes  exchange 
functions  from  message-passing  mechanisms,  where  (usually)  messages  ire 
automatically  buffered,  so  that  the  sender  transmits  the  message  and 
continues,  while  the  message  is  queued  until  the  receiver  is  ready  for  it. 

The  decision  against  this  scheme  is  based  on  our  concern  with 
performance.  Consider  a  set  of  terminals  sending  updates  to  a  central 
database.  With  exchange  functions  a  terminal  cannot  create  new  work  for  the 
system  until  the  system  has  accepted  its  previous  work.  If  a  terninal  could 
simply  send  an  update  message  and  continue,  Its  speed  could  increase 
(unchecked  by  the  ability  of  the  system  to  handle  the  work),  the  queue  at  the 
database  could  grow  to  unbounded  lengths,  and  no  bounds  on  the  performance  ^f 
the  system  could  ever  be  established. 

At  the  same  time,  there  Is  nothing  wrong  with  bounded  buffering,  but  this 
can  always  be  specified  in  PAISLey.  But  introducing  hounds  within  an 
abstract,  general-purpose  Interaction  mechanism  (such  as  "message  passing  up 
Co  some  bound")  would  seem  a  most  unfortunate  mixture  of  specification  and 
implementation. 

Given  that  synchronization  is  going  to  be  two-way,  it  costs  very  little 
in  the  implementation  to  preserve  the  possibility  of  two-way  data  transfer, 
although  it  is  seldom  used.  It  also  keeps  the  number  of  primitives  down  by  a 
factor  of  two,  since  otherwise  each  of  the  three  exchange  functions  would  have 
to  come  in  a  "sending  data"  and  a  "receiving  data"  version. 

Of  all  the  well-known  Interaction  mechanisms,  the  most  similar  to 
exchange  functions  is  Hoare's  input/output  primitives.  In  Hoare's  language,  a 
pair  of  statements,  "P?lnput"  in  process  Q  and  "Qloutput"  in  process  P,  will 
cone  together  in  the  sane  mutually  synchronized  manner  that  two  matching 
exchanges  do.  "Output"  is  an  expression  whose  value  is  assigned  to  the 
variable  "input",  assuming  appropriate  type  correspondences.  In  addition  to 
the  relatively  unimportant  data  asymmetry,  Hoare's  primitives  seem  to  he 
different  from  exchange  functions  in  three  fundamental  ways:  (1)  There  Is  no 
way  to  specify  real-time  or  free-running  interactions.  (2)  There  Is  no 
straightforward  way  to  specify  resource  sharing,  since  all  "matches"  are 
one-to-one  by  process  name.  In  Hoare's  language  a  process  representing  a 
shared  resource  must  have  a  separate  command  for  each  process  with  which  it 
can  communicate,  and  guard  that  command  ((Dljkstra  75])  with  an  Input  command 


naming  the  appropriate  process  of  the  many.  The  guard  (and  statement )  to  be 
executed  are  chosen  nondeterralnistlcally  from  the  processes  that  are  ready  to 
communicate.  These  multiple  statements  seem  distinctly  clumsy  compared  to  an 
”xin"/”x"  exchange  match.  Furthermore,  the  full  knowledge  each  process  must 
have  about  the  names  of  the  processes  with  which  it  coramvinicates  makes 
modularity  difficult  to  achieve.  (3)  Hoare's  primitives  belong  in  a 
procedural,  rather  than  applicative,  framework.  The  destination  of  a  data 
transfer,  for  Instance,  is  specified  by  an  address. 

5.4.  Performance  requirements 

5.4.1.  Definition  of  performance  requirements 

So  far  the  only  structure  that  has  been  needed  for  complete  and  formal 
specification  of  performance  requirements  is  attachment  of  timing  and 
reliability  attributes  to  functions  in  the  “functional”  requirements 
specification.  A  timing  attribute  refers  to  the  evaluation  time  of  the 
function.  It  is  a  random  variable,  and  any  information  about  its 
distribution,  such  as  lower  or  upper  bounds,  mean,  or  the  distribution  itself, 
may  be  given.*****  Timing  attributes  for  exchange  functions  are  attictied  to 
the  channel,  and  hold  for  all  interactions  on  that  channel. 

A  reliability  attribute  can  only  be  attached  to  a  function  vhi'.se  range  is 

divided  into  two  subsets  (e.g.  ” - >  SUCCESS-RESULT  U  FAI LURE-RESULT " ) ,  the 

first  for  the  values  returned  by  successful  evaluations,  and  the  second  for 
values  returned  when  the  evaluation  fails.  The  attribute  itself  is  a  discrete 
(binary)  random  variable  whose  two  outcomes  denote  successful  or  failed 
evaluations,  and  any  information  about  Its  dlstrlhvitlon  nay  be  given. 
Reliability  attributes  for  exchange  functions  are  attached  to  the  channel,  and 
hold  for  all  interactions  on  that  channel.  Furthermore,  wb.en  an  exchange 
function  falls  it  must  match  with  another  whose  evaluation  also  falls,  with 
the  values  of  both  being  selected  at  random  from  the  "failure"  suliscts  of 
their  ranges.  This  restriction  Is  made  so  that  failures  will  not  affect  ■  ; 
complicate  analysis  of  exchange  patterns.  Failure  of  a  nonprinltlve  function 
simply  means  that  it  delivers  a  value  In  the  second  subset  if  its  range. 

Reliability  is  a  difficult  and  little-understood  subject,  hut  tbls 
definition  of  it  has  several  appealing  properties.  It  forces  the  specified 
system  to  have  the  primary  characteristic  of  a  reliable  system,  namely  going 


Into  a  well-defined  and  previously  anticipated  state  when  something  fails.  It 
ouikes  reliability  Independent  of  timing  and  functionality,  since  a  function 
evaluation  must  satisfy  Its  timing  requirements  and  deliver  a  value  in  the 
declared  range  regardless  of  whether  It  succeeds  or  fails.  In  fact,  we  have 
deemed  this  property  so  Important  that  we  have  sacrificed  some  realism  for  it: 
only  primitive  functions  can  really  fall,  since  nonprimitive  ones  are  always 
evaluated  according  to  their  definitions.  Much  more  knowledge  of  reliability 
Is  needed  before  we  can  be  sure  how  successful  this  approach  will  be,  but  its 
formality  and  tractability  are  strong  arguments  in  its  favor. 

These  performance  requirements  can  be  simulated  by  the  specification 
Interpreter,  and  checked  (in  principle!)  for  internal  consistency,  just  as  the 
functional  ones  are.  This  means,  for  Instance,  that  if  "f[K)''  is  defined  as 
"g[h(x]I",  and  there  are  upper  bounds  on  the  evaluation  times  of  all  three, 
then  the  upper  bound  on  "f"  must  be  strictly  greater  than  (allowing  time  for 
Invocation/argument  transfer)  the  sum  of  the  upper  bounds  on  "g”  and  "h”. 

5.4.2.  Examples  of  "synchronous  closed-loop"  performance  requirements 

An  on-line  database  system  can  be  called  a  "synchronous  closed-loop" 
system — "closed-loop"  because  the  entire  feedback  loop  realized  by  the  system 
Is  explicitly  represented,  and  "synchronous"  because  the  terminal  process  (on 
behalf  of  the  cooperative  person  behind  it)  waits  for  responses,  i.e. 
synchronizes  Itself  with  the  system.  For  these  systems  the  basic  performance 
requirements  are  particularly  easy  to  specify,  and  all  are  attached  to  the 
terminals.  We  will  refer  to  the  functional  terminal  specification  in  5.2. 

A  response-time  limit  of  3  seconds  is  specified  by: 
transact;  "time  - >  maximum  ■  3  sec". 

(Performance  requirements  are  currently  just  comments  in  the  PAiSLey  syntax 
because  we  have  not  yet  settled  on  a  formal  language  for  distributions.)  An 
average  load  of  200  transactions  per  second  is  specified  by: 

terminal-cycle:  "tine  - >  mean  ■  30  sec", 

which  says  that  on  the  average  a  terminal  demands  a  transaction  (goes  through 
a  cycle)  every  50  seconds.  Finally,  the  requirement  that  at  least  99  per  cent 
of  all  transactions  must  be  processed  successfully  is  expressed  as; 

transact:  "reliability  - >  probf  'success'  i  >■  .99", 

which,  of  course,  can  only  be  attached  to  "transact"  because  its  range  is 
divided  into  success  ("RESPONSE")  and  failure  (  "ERROK-MF.SSAGF."  )  subranges. 


5. A. 3.  Examples  of  "asynchronous  closed-loop"  performance  requirements 


The  process-control  system  depicted  In  Figure  S  can  be  called  an 
"asynchronous  closed-loop"  system — "asynchronous"  because  Che  nachlnos,  which 
are  the  source  and  destination  of  the  major  feedback,  loop  realized  by  the 
system,  are  free-running.  The  system  must  keep  up  with  them  without  tt-.elr 
cooperation.  Performance  requirements  for  these  systems  are  more  of  a 
challenge,  but  the  operational  approach  enables  us  to  specify  then 
straightforwardly.  "Open-loop"  specifications.  In  which  not  all  of  the 
feedback  loop  (ultimately,  the  purpose  of  any  embedded  system  Is  to  realize 
feedback  loops)  is  Included  explicitly  In  the  model,  have  performance 
requirements  similar  to  these.  An  example  of  an  open-loop  specification  would 
be  a  patient-monitoring  system  in  which  treatment  of  patients  was  not 
represented,  only  display  of  warning  messages. 

We  will  now  present  the  timing  requirements  for  the  proces s-cont r 1 1 
system.  The  machine  processes  specified  in  5.3.3  were  designed  to  carry  out  a 
fixed-interval  simulation  with  step  tine  or  granularity  .1  second.  This  is 
specified: 

J^U..3<  ;  raachlne-j-cycle:  "time  - >  »  .1  sec"  >. 

Recall  from  4.1  that  there  are  two  closed  feedback  loops  r<M’.l.'ed  bv  t:-.is 
system.  The  fully  automatic  feedback  loop  for  conditions  local  to  ;  r.d  i  v;  duia  1 
machines  is  provided  by  the  "machlne-noni tor"  processes.  The  partially  nanui’. 
feedback  loop  for  dangerous  factory  conditions  Includes  thi'  "ma..- 1 1  r.i -t  p.  i  r  ^  • 
processes,  the  "factory-monitor"  process,  and  the  "operal  or"  process  direi-r  Iv¬ 
in  its  realization.  Factory  engineers  give  thijse  two  loo, os  . --  1 

limits  of  3  and  60  seconds,  respectively. 

The  automatic  feedback  loop  will  bo  considered  first.  T'-.e  eiccosp  r 
functions  of  the  machine  monitors  are  defined  as  follows: 

J//1.  .3 

<  ;  machine- j-monltor-cyc  le  :  MACHI.'JK- IMAGF - >  I'AcH  I '.K- [".ioK  ; 

machine- j-monltor-cyc le fm ]  » 

process-machine-  l-data(  (ra.itot-machliu-  -  j-dat  i  '  j ; 

get-machlne-J-data:  - >  SENSOR-DATA; 

get-machlne- J-data  «  x- j-sens ( 'mil  I' ] ; 
process-machine-J-data: 

MACHINE- IMAGF.  x  SEHSOR-DATA - >  MACH  I '.T,- IMA.;!. ; 

process-machinc-j-data((m,d) I  » 

proJ-3-l[ (ma intain-machine-lmaGe ( (m.dl ] , 

f  eedback-  j-1  f-needed  f clieck-mach  1  -'le-c  op.,i  1 1 1 oi.  |  ti  ,  i )  ’  , 


provlde-mach Ine-  )-dat(i  1  (m,d)  ) 

)  1  I 

malntaln-niachine-image : 

MACHINE-IMAGE  x  SENSOR-DATA - >  MACHI NE-IMAGF. ; 

check-tnachine-condl  t  Ion : 

MACHINE-IMAGE  x  SENSOR-DATA - >  FEEDBACK  U  ■'  'ok' 

feedback-j-if-needed:  FEEDBACK  U  {  'ok'  }  — >  FILLER; 

feedback- j-1 f-needed ( f ]  «  /equal I ( f , 'ok' ) ] :  'null', 

'true  :  f eedback- j [ f 1 

/; 

f eedback- j:  FEEDBACK  - >  FILLER; 

feedback- j [ f ]  •  xm- j-back ( f ] ; 

provlde-machlne-j-data:  MACHINE-IMAGE  x  SENSOR-DATA  - >  FILLER 

>. 

A  monitor  begins  Its  step  by  getting  sensor  data  iron  Its  machine  (see  3.3.3). 
"Process-machine- j-data"  does  three  things  In  parallel  with  that  Information: 
(I)  update  an  "image"  of  the  machine  which  Is  kept  In  the  process  state  for 
the  purpose  of  making  history-sensitive  decisions,  (2)  check  to  see  If 
feedback  Is  needed  and  if  so  provide  it,  and  (3)  offer  edited  forms  of  the 
sensor  data  to  other  parts  of  the  system.  Note  that  the  automatic  feedback 
loop  is  completely  contained  within  one  cycle  of  a  machine  monitoring  process. 
This  means  that  the  necessary  formal  performance  requirement  is  simply: 

J//l..3<  ;  raachine-J-monitor-cycle :  "time - >  maximum  =  3  sec"  >. 

Since  the  other  feedback  loop  involves  action  by  the  environment  (the 
operator)  as  well  as  the  system,  performance  allocation  of  the  t30-second 
leeway  must  be  included  in  the  requirements.  Perforruince  allocation  is 
normally  a  design  activity,  but  this  is  a  typical  exinple  of  the  frequent  need 
to  handle  "design-like"  decisions  at  the  requirements  level.  If  the  operatir 
is  allocated  50  seconds  to  respond  to  the  alarm,  this  decision  can  bo 
documented  by  specifying: 

operator-cycle:  "time  - >  maximum  »  50  sec", 

since  the  operator's  response  to  an  alarm  is  completely  coot  lined  within  one 
cycle  of  that  process- 

The  "factory-iaonl  tor"  process  is  very  similar  to  tin'  "machlne-r.onltnr" 
processes,  except  that  it  gets  its  data  from  the  machine  monitors  instead  of 
the  machines,  and  responds  to  detecting  an  undesirable  condition  hy  notifying 
the  operator  instead  of  interacting  with  the  machines.  Thus  the  vitonatlc 
part  of  this  feedback  loop  is  completely  contained  within  one  cvcle  cf  the 
"factory-monitor"  process,  with  the  understanding  that  the  data  it  receives 


much  .IS  1  socoiiils  iill. 


from  the  machine  monitors  may  already  be  .is 
obvious  conclusion  Is  that  the  factory  monitor  mu.st  complete  Its  .-vcle  ulthl-i 
60  -  50  -  3  ■  7  seconds: 

factory-monitor-cycle:  "time - >  naxlmun  =•  7  sec”. 

Both  the  machine  monitors  and  the  operator  need  to  .iccess  tl-.e  djtabi-.e 
during  their  cycles,  and  therefore  depend  on  database  response  to  meet  their 
own  performance  requirements.  Although  It  Is  not  necess.iry  until  tlie  ,ii  sU:n 
phase,  we  can  derive  a  performance  requirement  for  the  database  that  will 
guarantee  adequate  service,  assuming  an  implementation  with  rCFS  scliedu  H  n,- , 
such  as  that  In  5. 3. A.  (We  know  of  no  reasonable  method  besides  FCFS  queucinn, 
for  preventing  lockout.)  Let  us  say  that  every  process  must  be  gmr.inret-d  a 
database  response/access  time  of  2  seconds,  which  we  judge  will  en.ible  b  i''. 
machine  monitors  and  the  operator  to  satisfy  their  other  constraints.  Since 
Interactions  are  mutually  synchronized,  no  process  can  go  .ut  to  create  more 
work  for  the  database  until  its  previous  request  has  been  processed.  Ti;is 
means  that  the  maximum  number  of  outstanding  requests  is  five  (five  processe'- 
have  access  to  the  database),  and  a  time  limit  of  seconds  will  gu.iriiitee 
that  all  are  honored  within  2  seconds: 

database-cycle:  "time - >  maximum  =•  .4  sec". 

5.4,4.  "Real-world"  properties 

Time  and  reliability  (the  fact  that  sometimes  digital  'om.penen' s  do  lo; 
do  what  their  definition  says  they  will,  for  pbvsic.il  r.’.i sor.n.  f  ir'''  -''‘r  b.'v'n.i 
the  reach  of  digital  logic)  are  nondigital  properties  tii.ii  i  n.con.r  rove  rt  i  '  Iv 
affect  the  digital  domain.  In  [Lave  .SObj  n.inv  .jth.’r  su physin.i'. 
("real-world")  properties  are  mentioned,  weight  and  liiscanco,  f  >;■  example. 
Why  aren't  these  performance  requirements  as  well? 

The  answer  Is  that,  to  the  extent  that  we  know  them,  the  effects  of  thes.' 
properties  on  the  computational  (digital)  domain  can  he  specified  in  terms  of 
functions,  timing,  and  reliability.  Weight  constraints,  for  instance,  onl" 
affect  how  many  functions  can  be  realized.  Even  if  ue  p,  )  at'  u>,  weichi 
attributes  to  components  of  a  PAISLe.y  specification,  there  is  n.'!  h  i  I'.c,  that  an 
Interpreter  could  do  with  them.  Therefore  an  Inform.il  -o-.nont  Is  just  is 
satisfactory . 

Distance  Is  a  more  Interesting  example  hec.iuse  its  ef  f.jrts  on  the 
computational  domain  are  more  varied.  Distance  Increases  the  rniativc  tlm,' 


for  interprocess  Interactions,  decreases  component  reliability,  and  Increases 
the  logical  complexity  of  interfaces  which  must  cope  with  these  factors.  Yet 
these  three  effects  are  directly  expressable  in  terms  of  timing,  reliability, 
and  functional  requirements,  respectively. 

Factors  such  as  these  can  have  a  profound  effect  on  requirements.  In  an 
airline  reservation  system,  for  Instance,  it  may  be  necessary  to  divide  the 
response-time  or  transaction-reliability  allowances  into  portions  for  the 
data-communication  subsystem  and  portions  for  the  database  subsystem. 
Although  (as  mentioned  before)  allocation  is  technically  a  design  decision, 
two  additional  reasons,  both  applicable  here,  for  doing  it  during  the 
requirements  phase  are;  (I)  to  enable  feasibility  analyses  of  tvo  very 
different  technologies,  and  (2)  to  contract  the  work  to  different 
organizations . 

These  allocated  requirements  can  be  specified  in  PAISI.ey.  Vc  have 
constructed  a  requirements  model  in  which  time  limits  are  given  for,  and 
failures  can  occur  in,  each  of  three  stages:  input  transmission,  transaction 
processing,  and  output  transoilssion.  Fall;ire  at  any  stage  aborts  subsequent 
stages  and  propagates  an  appropriate  error  message.  This  Is  the  source  of 
elements  In  the  set  "ERROR-MESSAGE'’  found  In  the  range  of  "transact”  in  the 
terminal  specification. 


6.  INTERIM  EVALUATION 


How  well  do  PAISLoy  specifications  meet  the  goals  of  1.2?  ilop u  1  reno lU  s 
written  in  this  language  are  certainly  precise ,  unambiguous ,  and  ■; x e c u t a b I e , 
and  can  be  determined  to  be  Internally  consistent .  We  have  argued  fhac  the 
language  allows,  and  perhaps  even  encourages,  sped  f  Icat  lor.s  to  bo  -oJl  f  lab  le  , 
Intuitive ,  and  minimal . 

Experience  has  Indicated  chat  PAISLey  allows  complete  specification  of 
requirements  properties  relevant  to  the  computational  domain.  It  savs  nothing 
about  constraints  on  the  development  process  Itself,  such  a--  deadlines,  cost 
limits,  methodological  standards,  and  routine  maintainance  pr ’-i' lures .  It  is 
also  not  particularly  helpful  In  posing  alternate  or  prior; t  iced  requi rericnts 
( (Yeh  al^*  80J),  And  the  need  to  supplement  forcil  roijui  revieit  s  with 
diagrams,  comments,  and  other  Informal  avenues  of  l)i;ran  .-ommun  I  ca  t  i  on  .ill 
never  disappear. 

PAISLey  also  enables  nontrivial  decomposl  t  ion  d  I  e\- !  t  y  In  all  threu 

ways.  The  division  of  a  sped  ficatlon  into  processes  is  an  '’.specially  useful 
form  of  partition,  because  it  decomposes  both  static  and  dyn.imic  pr. ’perries, 
and  becau.se  it  correlates  fairly  well  with  our  abstract.  Intuitive  notion  of 
system  "functions".  The  partitioning  even  extend.s  to  cxu'catlon  of 
specifications,  because  any  subset  of  processes  can  be  executed  in  isolati  n, 
simply  by  leaving  all  Interactions  with  missing  prnco.sses  an  u:ie  1  ahor  n ;  oii 

primitives  In  a  form  such  as  "recelve-message  : - >  NES.SAOE".  The  i  n  t  e  rpr  et  e  r 

wlll  evaluate  this  "interaction  site"  by  choosing  some  m'-’.';s.a,e  at  random. 
This  capability  was  used  In  [Zave  &  Yeh  81)  to  develop  a  s peci f i ca t  ion  In  five 
versions,  each  Independently  executable,  and  each  obtained  from  thn  last  hr 
adding  new  processes/ funct ions  in  an  "out.slde-in”  sequence. 

A  projection  decomposes  complexity  by  representing  onlv  a  uh'iet  of  •.  lo 
system's  properties.  Performance  attributes  are  di'fined  c-o  rhi;  :'ne 
functional  specification  is  independent  of  its  perforna.’ce  pr ’pert  lea,  .u'.'i 
timing  and  reliability  are  independent  of  each  otlier,  both  very  usi-ful  forms 
of  projection.  Furthermore,  by  elaborating  a  specification  oniv  until  ill 
process  interactions  and  control-oriented  functions  at'-  .’xp’i  it  .".o;; 

natural  thing  to  do  in  PAISLey!),  and  by  then  spedfvlng,  fh.e  pri  vdive  o'rs 
and  da  ta-manlpulat  ion  functions  in  a  data-oriented  spec!  f  i  ■  i  >.  iop.  lui.-uvge,  t''.e 


analyst  can  achieve  an  almost  perfect  projection  of  his  nnilerlyln>;  noticl  onto 
process-oriented  and  data-oriented  views. 

Within  processes,  state  replacement  (rather  than  assignment)  and 
applicative  notation  offer  unsurpassed  opportunities  for  abstraction. 
Applicative  languages  actually  force  the  user  tj  create  an 
abstractlon/elaboratlon  hierarchy,  while  the  high-level,  but  procedural, 
languages  now  being  proposed  as  design  notations  continually  disrupt  It  with 
assignment  statements.  Processes,  however,  do  not  lend  themselves  so  readily 
to  hierarchical  representations.  More  research  is  needed  in  this  area  (see 
7.2,  where  formal  manlpulablllty  is  also  mentioned). 


7.  PLAN'S  FOR  FUTURE  RESEARCH 


7.1.  Experience 

We  have  plans  to  Implement  a  specification  interpreter  ..ith  Gi-.tile 
consistency-checking,  so  as  to  gain  experience  with  the  i.r.pact  of  cxecntib;- 
speclflcatlons  on  the  requirements  development  process.  This  will  inclide 
consideration  of  the  language  front-end,  and  Inves  t  i  g.i  t  ion  if  the  displ.iv, 
report,  and  trace  facilities  needed  for  the  results  <if  execution. 

7.2.  Methodology 

This  work  on  requirements  specification ,  which  h.is  been  j-ursueri  so  for 
with  small  examples,  must  be  extended  in  tin?  directions  of  requi reoent = 
analysis ,  and  "scaling-up"  to  large  systems.  Roth  problems  will  atta-Keo: 

by  looking  for  an  abstraction  methodology  for  pro(  es-.-h.ised  spec  i  ficat  i  oi'.-- , 
l.e.  a  technique  for  conceiving  of  and  specifylm;  a  rvstnm  nf  Intern,  t  ir.c 
processes  as  a  top-down  hierarchically  structured  set  'f  sped f i  'nt ions .  Tie 
technique  for  developing  a  top-down  hierarchy  would  provide  a  trial  analysis 
methodology,  and  the  existence  of  the  hicrarcliy  would  -ss’st  u-.ilvsts  ii 
handling  the  complexity  of  large  systems. 

There  are  several  precedents  to  follow  In  -ni  ;  ir:  .  r  -  It  ; 

well-known  arrangement  of  processes  themselves  in  a  '' I  'ra  rcl- 1  -  a stra.  i  :r 
where  processes  at  higher  levels  "give  work  to  "  pr -jcess.^ s  at  v' a- r 
([Parnas  74]);  this  will  bo  helpful  for  requirements  i aai  i  i'  th.' 

hierarchies  so  created  coincide  with  some  ratio. lal  hies;;-,  ■  f  ■■  t  m 

"functions",  seen  from  the  requirements  vlewp.iint.  A:io' 

aggregation  of  related  processes  Into  "subsystems",  as  in  ri[v;  j...,.  ,,  al. 

78]).  There  Is  clearly  some  correlation  r.'tw.'-'. 

(requirements  view)  and  proces.ses  In  ovir  exampl.'  sa'v  i:  !  i  -■  ,  ,  e  . 

encouraging  sign;  furthermore,  many  of  the  s.ime  p.,t!  'i-is  -t  p,- 
observed  over  and  over  again  in  embedded  systems. 

One  other  possibility  is  the  use  of  purely  appli  ad  e  i!i:i  a  a;  i’ 
applied  in  [Smollar  79]  and  [Friedman  ?■  '..’Ise  7'’],  i.'.  ;o  ■  -  i  :  aril'..  1  vi 

distributed  system  concepts  in  a  way  that  is  more  il  stru  t  tl.  in 
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notation  could  bo,  because  of  the  total  lack  of  states  (the  conconitant 
disadvantage  is  inability  to  deal  with  performance  or  free-running  Interfaces, 
see  [Zave  SOa]).  By  establishing  some  formal  equivalences  between  these  two 
notations,  we  may  be  able  to  exploit  some  of  the  formal  manipulabl llty  and 
power  of  abstraction  characteristic  of  applicative  languages  for  our  own, 
process-oriented,  purposes, 

7.3.  Design 

It  has  been  pointed  out  that  PAISLey  is  capable  of  specifying  the  results 
of  design  decisions.  A  logical  extension  of  this  is  to  investigate  its 
properties  as  a  design  specification  language.  The  benefits  are  potentially 
great,  because  a  uniform  language  for  requirements  and  design  should  make 
possible  substantial  Improvements  in  the  traceability  and  autonacability  of 
design.  It  might  also  lead  to  a  better  theoretical  understanding  of  design 
decisions  as  resource/performance  trade-offs. 


8.  CONCLUSION 


It  would  not  be  seemly  to  end  a  paper  as  long  as  this  without  a 
conclusion,  but  there  is  little  left  to  say. 

In  addition  to  the  varied,  but  small,  examples  discussed  here,  PAISLey 
has  been  used  to  specify  (in  some  33  pages)  a  distributed  design  for  an 
innovative  interactive  numerical  system,  and  the  system  has  been  implemented 
directly  from  that  specification.  Throughout  the  project  the  specification 
has  served  successfully  as  an  interface  between  the  numerical  and 
distributed-system  domains,  both  for  human  communication  and  for  executable 
code  (fZave  &  Rhelnboldt  79],  (2ave  78],  (2ave  &  Cole  81)). 


ACKNOULEDGMENTS 


Many  people  have  contributed  to  the  work,  presented  here.  My  thanks 
especially  to  Bob  Fltzwater,  with  whom  Che  foundations  for  PAISLey  were  laid, 
to  Steve  Smollar,  Alex  Conn,  and  Roland  Mlttermelr,  for  stimulating 
discussions  on  requirements,  to  Priscilla  Fowler,  for  the  chance  Co  try  these 
Ideas  on  a  class  at  Bell  Labs,  to  George  Cole,  for  diligent  and  able 
assistance,  to  Dick  Hamlet,  who  would  read  this  scuff  before  anyone  else  would 
(or  could),  and  to  Raymond  Yeh,  for  support,  encouragement,  ideas,  and  good 
advice . 


REFERENCES 


(Air  Force  65] 

U.S.  Air  Force,  "Air  Force  Weapons  Effectiveness  Testing  (AFWET) 
Instrumentation  System",  R&D  Exhibit  No.  PGVE  64-60,  Air  Proving  Ground 
Center,  Eglln  Air  Force  Base,  Florida,  1965. 

(Alford  771 

Mack  w.  Alford,  "A  Requirements  Engineering  Methodology  for  Real-Time 
Processing  Requirements",  IEEE  Trans.  Software  Engr.  Sr.-3,  January  1977, 
pp.  60-69. 

(Backus  78] 

John  Backus,  "Can  Programming  be  Liberated  from  the  von  Neumann  Style?  A 
Functional  Style  and  its  Algebra  of  Programs",  Comm.  ACM  21,  August 
1978,  pp.  613441.  -  -  — 

(Balzer  &  Goldman  79] 

Robert  Balzer  and  Nell  Goldman,  "Principles  of  Good  Software 
Specification  and  Their  Implications  for  Specification  Language",  Proc. 
Specifications  of  Reliable  Software  Conf .  ,  Cambridge,  Mass.,  April  19  79, 
pp.  58-67. 

(Belady  &  Lehman  791 

L.A.  Belady  ana  M.M.  Lehman,  "The  Characteristics  of  Large  Systems", 
Research  Directions  in  Software  Technoloev,  Peter  We.gner.  ed.'.  M.I.T. 
Pfess,  Cambridge,  Mass.,  1979 ,  pp.  106-T38. 

(Bell  et  al^.  77] 

Thomas  E.  Bell,  David  C.  Bixler,  and  Margaret  E.  Dyer,  "An  Extendable 
Appraoch  to  Computer-Aided  Software  Requirements  Engineering",  IEEE 
Trans .  Software  Engr.  SE-3 ,  January  1977,  pp.  49-60. 

(Bell  &  Thayer  761 

T.E.  Bell  and  T.A.  Thayer,  "Software  Requirements:  Are  They  Really  a 
Problem?",  Proc.  2nd  Inti.  Conf.  on  Software  Engineering,  Sah  Francisco, 
Cal.,  October  1976,  pp.  61-68. 

(Boehm  76] 

Barry  W.  Boehm,  "Software  Engineering",  IEEE  Trans.  Computers  C-25, 
December  1976,  pp.  1226-1241. 

(Brlnch  Hansen  77] 

Per  Brinch  Hansen,  The  Architecture  of  Concurrent  Prograns, 
Prentice-Hall,  Inc.,  1977T  “ 


(Brlnch  Hanncn  781 

Per  Brlnch  Hansen,  "Distributed  l’ri>eess«!s ;  A  i'i>tu'ni  rent  'r'ro^r.iiHnil 
Concept",  Comm.  ACM  2 1 ,  November  1978,  pp.  939-941. 

(Conn  80] 

Alex  Paul  Conn,  "Maintenance:  A  Key  Element  in  Computer^  Requirenents 
Definition",  Proc.  COMPSAC  '80,  Chicago,  Ill.,  October  1980,  pp.  401-406. 

(Davis  &  Rauscher  79] 

Alan  M.  Davis  and  Tomlinson  G.  Rauscher,  "Fornal  Techniques  and  Autor..itic 
Processing  to  Ensure  Correctness  in  Requirements  Specifications",  Proc. 
Specifications  of  Reliable  Software  Conf.,  Cambridge,  Mass.,  April  1979, 
pp.  15-35. 

(Davis  &  Vick  77] 

Carl  G.  Davis  and  Charles  R.  Vick,  "The  Software  Development  System", 
IEEE  Trans .  Software  Engr .  SE-3,  January  1977,  pp.  69-84. 

(Dljkstra  75] 

E.W.  Dljkstra,  "Guarded  Commands,  Nondetermlnacy ,  and  Formal  Derivation 
of  Programs",  Comm.  ACM  18,  August  1975,  pp.  453-457. 

(Fisher  78] 

David  A.  Fisher,  "DoD's  Common  Programming  Language  Effort",  Computer  11, 
March  1978,  pp.  24-33.  s  o  s  - 1 - 

(Fllman  &  Friedman  80] 

Robert  E.  Fllman  and  Daniel  P.  Friedman,  Languages  and  '■lodels  for 
Distributed  Computing ,  to  appear.  ~  " 

(Fltzwater  &  Zave  77] 

D.R.  Fltzwater  and  Pamela  Zave,  "The  Use  of  Formal  Asynchronous  Process 
Specifications  in  a  System  Development  Process",  Proc.  6th  Texas  tlonf. 
on  Computing  Systems,  Austin,  Texas,  November  1977,  pp.  2B-21  -  2B-30. 

(Frankel  79] 

R.E.  Frankel,  "FQL — The  Design  and  Implementation  of  a  Functional 
Database  Query  Language",  Unlv.  of  Penn.  Decision  Sciences  79-05-13. 
Philadelphia,  Penn. ,  19/9. 

(Friedman  4  Wise  77] 

Daniel  P.  Friedman  and  David  S.  Wise,  "Aspects  of  Appl Icit ivv  Prograv'- ! n  , 
for  File  Systems",  Proc.  ACM  Conf.  on  I.anguage  Desig:!  fvr  Rol 
Software,  Raleigh,  N.  Car.,  March  1977,  pp.  41-55. 

(Friedman  &  Wise  78a) 

Daniel  P.  Friedman  and  David  S.  Wise,  "Aspects  of  Anpl  ic.it  Ivo  rrtu>;%i".''.t  r  .• 
for  Parallel  Processing",  IEEE  Trans.  Computers  C-ll/,  April  19/8,  rn. 
289-296.  - - - - 

(Friedman  &  Wise  78b] 

Daniel  P.  Friedman  4  David  S.  Wise,  "Unbounded  Computational  structures". 
Software — Practice  and  Experience  8,  July-August  1978,  pp. 

[Friedman  4  Wise  79] 

Daniel  P.  Frlearaan  and  David  S.  Wise,  "An  Approach  to  Fair  Applicative 
Multiprogramming",  Semantics  of  Concurrent  Computation  I'C.  Kann,  e!.), 
Lecture  Notes  in  Computer  science  70,  Springor^erlag  ,  “ITe  r  It  n .  nr. 

203-226, 

(Friedman  4  Wise  80] 

Daniel  P.  Friedman  and  David  S.  Uls.’,  "An  Indot  crni  na  tp  Cmstrurt  .r  ;  r 
Applicative  Programming",  Proc.  7th  Annual  ACM  Svmp.  on  Pr i nc i n 1 'c  t. 
Programming  Languages,  Las  Vegas,  Nev.  ,  January  198D',  pp.  2  45-2  50  . 

(Heninger  79] 

Kathryn  L.  Heninger,  "Specifying  Software  Roquireaonts  for  loTcle-; 
Systems:  New  Techniques  and  Tneir  Application",  Fr'C.  sped  “"i -at  lens  -f 

Reliable  Software  Conf.,  Cambridge,  Mass.,  April  1979,  pp.  l-l*. 

(Hoare  74] 

C.A.K.  Hoare,  "Monitors:  An  Operating  System  Structurin.t  Concept", 


August 


ACM  1 7 ,  October  1974,  pp.  549-557. 


(Hoare  78] 

C.A«R<  Hoare,  "ConmunlcntlnK  Sequential  Processes",  Comm.  ACM  21, 

1978,  pp.  666-677,  - - - 

(Horning  &  Randell  73] 

J.J.  Horning  and  B.  Randell,  "Process  Structuring",  Computing  Surveys  s 
March  1973,  pp.  5-30.  - - -  - -  - 

(Ichblah  et  al.  79] 

J.D.  Ichblah  et  al.,  "Rationale  for  the  Design  of  the  Ada  Programming 
Language",  SITTPLAIT  Notices  14,  June  1979,  Part  B. 


(Ingalls  78] 

Daniel  H.H.  Ingalls,  "The  Smalltalk-76  Programming  System  Design  and 
Implementation  ,  Proc.  5th  Annual  ACM  Symp.  on  Principles  of  Programming 
Languages,  Tucson,  Ariz.,  January  1978,  pp.  9-16. 


(Iverson  80] 

Kenneth  E.  Iversion,  "Notation  as  a  Tool  of  Thought",  Comm.  ACM  23. 
August  1980,  pp.  444-465.  " 


(Knight  72] 

John  R.  Knight,  "A  Case  Study:  Airlines  Reservations  Svstens",  Proc.  of 
the  IEEE  60,  November  1972,  pp.  1423-1431.  -  — 

(Mao  &  Yeh  80] 

William  T,  Mao  and  Raymond  T.  Yeh,  "Communication  Port:  A  Language 
Concept  for  Concurrent  Programming",  IEEE  Trans,  Software  Engr,  SE-o, 
March  1980,  pp.  194-204.  - — -  — - 

(Milne  &  Milner  79] 

Ceorge  Milne  and  Robin  Milner,  "Concurrent  Processes  and  Their  Svnta.<  . 
Jour.  ACM  26,  April  1979,  pp.  302-321. 

(Mltteraelr  80] 

Roland  T.  Mltterraelr,  "Semantic  Nets  for  Modeling  tlie  Requirements  of 
Evolvable  Systems — An  Example",  Institut  ruer  Digitale  Anlagen, 
Technlsche  Unlversltaet  Wien,  Vienna,  Austria,  May  1980. 

(Parnas  74] 

David  L.  Parnas.  "On  a  'Buzzword':  Hierarchical  Struct\jre",  Proc.  IFI? 
Congress,  Stockholm,  Sweden,  1974. 

(Rao  80] 

Ram  Rao,  "Design  and  Evaluation  of  Distributed  Communication  Primitives', 
Unlv.  of  Wash.  Computer  Science  80-04-01,  Se.attle,  Wash.,  April  1930. 


(Riddle  ft  al.  78] 

W 1 ITTam  t .  Riddle  et  al.,  "Behavior  Modeling  During  Software  Design", 
IEEE  Trans .  Sof twaTg  CTTgr .  SE-4,  July  1978,  pp.  283-292. 

(Ross  77] 

Douglas  T.  Ross,  "Structured  Analysis  (SA):  A  Language  for  Connunicat ing 
Ideas",  IEEE  Trans .  Software  Engr.  SF.-3 ,  January  1977,  pp.  16-3'<. 

(Ross  &  Schoman  77] 

Douglas  T.  Ross  and  Kenneth  R.  Schoman,  "Struct>ired  Analvsls  ;  ^r 
Requirements  Definition",  IEEE  Trans.  .Software  Engr.  .SE-3,  Janu.irv  1^71. 
pp.  6-15.  — ’ 


(Roussopoulos  79] 

Nicholas  Roussopoulos,  "CSDL:  A  Conceptual  Schema  Definition  Langu.sge  fer 
the  Design  of  Data  Base  Applications",  IEEE  Trans.  Software  Engr.  SL-3, 
September  1979,  pp.  481-496.  — ^ — - - 

(Smith  4  Smith  79] 

John  Miles  Smith  and  Diane  C.P.  Smith,  "A  D.ata  Fl-ase  A:  proach  t  '  Software 
Specification",  Proc.  Software  Development  To.ils  Wnri'shop,  Plngree  rar'-. 
Colo.,  May  1979.  (Sprlnger-Verlag,  W.E.  Riddle  and  R.F..  Fairlev,  eis., 
1980),  pp.  176-JOO. 


(Smollar  79] 

Stephen^W.  Smollar,  "Using  Applicative  Techniques  to  Design  Distribute.! 
Systems",  Proc.  Specifications  of  Reliable  Software  Conf.,  Cambridge, 
Mass.,  April  1979,  pp.  150-161. 

[Smollar  80] 

Stephen  W.  Smollar,  "Applicative  and  Functional  Programming",  Software 
Engineering  Handbook,  C.V.  Raraaraoorthy  and  C.R.  Vick,  ^ds . , 
Prentice-Mall,  Itic. ,  To  appear. 

[Telchroew  &  Hershey  77] 

Daniel  Teichroew  and  Ernest  A.  Hershey  III,  "PSL/PSA:  A  Computer-Aided 
Technique  for  Structured  Documentation  and  Analysis  of  Infomarlon 
Processing  Systems",  IEEE  Trans.  Software  Engr.  SE-3,  January  1977,  pp. 
41-48.  - - - 


[Yeh  et  aj^.  79a] 

■Raymond  T.  Yeh  et  ^.  ,  "Software  Requirement  Engineering — A  Perspective  ", 
Univ.  of  Texas  TTonputer  Science  SDBEG-7,  Austin,  Texas,  March  1979. 

[Yeh  et  al.  79b] 

■RayWCnd  T.  Yeh,  Nick  Roussopoulos,  and  Philip  Ch.mg,  ■Systematic 
Derivation  of  Software  Requirements  Through  Structured  Analvsls",  'niv. 
of  Texas  Computer  Science  SDBEG-15,  Austin,  Texas,  1979. 

[Yeh  et  al.  80] 

■Ra'ymond  T.  Yeh  et  al.,  "Software  Requirements:  A  Report  on  the  State  of 
the  Art",  UnlVT  "Uf  Maryland  Computer  Science  TR-949,  College  Park, 
Maryland,  October  1980  (to  appear  as  "Software  Requirements:  New 

Directions  and  Perspectives"  in  Software  Engineering  Handbook,  C.V. 
Ramamoorthy  and  C.R.  Vick,  eds.  ,  Prent ice-lla  1  i ,  Inc  . ) . 

[Yeh  &  Mittermelr  80] 

Raymond  T.  Yeh  and  Roland  T.  Mittermelr,  "Conceptual  'ioieling  as  a  Basis 
for  Deriving  Software  Requirements",  Proc.  Inti.  Computer  Svmp.,  Taipei, 
Taiwan,  December  1980,  to  appear. 

[Zave  78) 

Pamela  Zave,  "The  Formal  Specification  of  an  Adaptive,  Parallel 

Finite-Element  System",  Univ.  of  Marvland  TR-715,  College  Park,  Marvland, 
December  1978. 

[Zave  80a 1 

Pamela  Zave,  "Applicative  Specifications  of  Distribute; 

Extending  tliera  to  Embedded  Systems",  submitted  for  publication,  1980. 

[Zave  80bJ 

Pamela  Zave 
Systems" , 


Md. 


"'Real-V/orld'  Properties  In  the  Requirements  for  Enb 
roc.  I9th  Annual  Wash.,  D.C.  A'"'t  Tech,  '^ym.p.,  Calttie^s 


June  1980,  pp.  21-26. 


irg  . 


.’a  lu.i ' 
f  r , 


1  ■  n  0  : 
an  Ada; 


[Zave  4  Cole  81] 

Pamela  Zave  and  George  E.  Cole,  Jr.,  "A  0\j.ir,t  i  tat  ie 
Feasibility  of,  and  Suitable  Hardware  Architecture 
Parallel  Finite-Element  System",  in  preparation. 

[Zave  &  Rhelnboldt  79] 

Pamela  Zave  and  Werner  C.  Rhelnboldt,  "Design  of  an  Al.tpi-fv.',  Pirill-'’ 
Finite-Element  System",  ACM  Trans  .  Ma  t  h  .  Sof  twa  rn  ,  M,tr-li  10,’o_  pj,. 


[Zave  4  Yeh  81] 

Pamela  Zave  and  Ravraond  T.  Yeh,  "Executable  Requl  remo!!!  s  tor  Enb.'dii'  , 
Systems",  Proc.  5th  Inti.  Conf.  on  Software  Engr.,  '^■in  Di.'go,  I'.il.,  M.ir'-h 

1981 ,  to  appear. 


APPENDIX:  A  GRAMMAR  FOR  PAISLEY 


This  grammar  is  LALR,  and  is  written  in  RNF  with  nonterminals  underlined. 

Comments  are  transparent,  and  can  therefore  appear  anywhere.  Blanks  are  also 
transparent,  except  Inside  an  ascii-string. 

comment  : :■  "ascii-string" 


.  integer 
.  integer 


spec  : spec  ;  statement  I 
statement  I 

spec  ;  index-head  <  ;  spec  >  I 
index-head  <  ;  spec  > 
index-head  :  :■  lower-string  If  integer  . 

upper-string  If  integer  . 
If  integer  .  .  integer 
statement  system-decl  I 


func-decl 


set-defn  I 


func-def n 


system-decl  : :■  (  process-list  ) 
process-list  : :■  process-list  ,  process  I 
process  I 

process-list  ,  index-head  <  ,  process-lis 
index-head  <  ,  process-list  > 
process  ; :■  f unc-name  [  f unc-exp  ] 


func-decl  : :■  func-name  ;  f 


f unc-property  ; :•  domain-range  I 


attribute  I 


reliabilit 

domain-range  : 

;  :■  set-exp - 

- >  set-ex 

timing-attribute  : :•  comment 
reliability-attribute  comment 


set-defn  ; ;■  set-name  ■  set-ex 


aet-exp  : :■  set-exp  U  set-tenn  | 
aet-term  1 

aet-exp  U  Index-head  <  U  set-exp  >  I 
Index-head  <  U  set-exp  > 
set-tenn  : : •  set-tenn  x  set-item  I 
set-item  1 

set-tenn  x  Index-head  <  x  set-tenn  >  I 
Index-head  <  x  set-tenn  > 
set-item  : :■  set-name  I 

(  set-exp  )  I 
{  const-list  } 

set-name  : :»  upper-string  -  set-name-str Ing  I 
upper-string 

set-name-string  : :■  set-name-string  -  set-syll  i 

set-syll 

set-syll  : : »  upper-string  I 
Integer 

const-list  ; ;■  const-list  ,  const-name  1 
const-name 

const-name  : :«  'ascll-strlng^  I 
Integer  I 
real-number 


func-def n  ;  : ■  f unc-nam>'  ”  f unc-exp  I 

func-name  f ormal-params  »  f unc-exp 
formal-pararas  : [  param-llst  ] 
param-llst  : :■  param-llst  ,  func-name  1 
func-name  I 

param-llst  ,  (  param-llst  )  I 
(  param-llst  ) 
f unc-exp  : : “  func-name  I 
conat-name  I 
f unc-appl  I 
(  func-llst  )  I 

/  pred-pal r-llst  ,  'true'  :  func-exp  / 
f unc-appl  :  :■  func-name  [  func-exp  ]  I 


6(1 


Index-head  <  func-name  >  {  func-exp  ) 
func-llst  : :■  func-llst  ,  func-exp  I 
func-exp  I 

func-llst  ,  Index-head  <  ,  func-llst  >  I 
Index-head  <  ,  func-llst  > 
pred-palr-llst  ; pred-palr-llst  ,  pred-palr  I 
pred-palr  I 

pred-palr-llst  ,  Index-head  <  ,  pred-palr-llst  >  i 
Index-head  <  ,  pred-palr-llst  > 
pred-palr  : : ”  func-exp  :  func-exp 
func-name  ; :■  lower-string  I 

lower-string  -  func-name-strlng 
f unc-name-strlng  : func-syll  -  func-name-strlng  I 

f(jnc-syll 

func-syll  : :■  lower-string  I 
Integer 


Primitives  of  the  grammar. 

ascll-strlng  ; :»  any  string  of  ASCII  characters 

upper-string  : any  string  of  upper-case  alphabetical  characters  (note  that 
"u  is  also  an  operator,  and  should  not  be  generated  as  a  set-nane  ) 

lower-string  : ;=•  any  string  of  lower-case  alphabetical  characters  (note  that 
x"  13  ald6  an  operator,  and  should  not  be  generated  as  a  func-name ) 

Integer  ; any  string  of  numerals 

real-number  : :■  any  string  of  numerals  with  a  single  embedded  period 


Intrinsic  sets. 

FILLER  -  (  'null'  } 

BOOLEAN  ■  {  'true',  'false'  } 

INTEGER  ■  the  set  of  all  Integers  representable  on  the  host  machine 

REAL  “  the  set  of  all  real  numbers  representable  on  the  host  machine 

STRING  ■  the  set  of  all  string  constants  with  length  less  than  or  Mj-.ial 
some  bound 

Typeless  Intrinsic  functions. 

x-lower-strlng  I  xm-lower-strtng  I  xr-lower-strlng 
pro j-lnteger-lnteger 


equal 
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Typed  intrinsic  functions. 

sum:  INTEGER  x  INTEGER  — >  INTEGER 

difference:  INTEGER  x  INTEGER  -->  INTEGER 

product:  INTEGER  x  INTEGER  — >  INTEGER 

quotient:  INTEGER  x  INTEGER  -->  INTEGER 

remainder:  INTEGER  x  INTEGER  — >  INTEGER 

greater-than:  INTEGER  x  INTEGER  — >  BOOLEAN 

less-than:  INTEGER  x  INTEGER  — >  BOOLEAN 

greater-than-or-equal:  INTEGER  x  INTEGER  -->  BOOLEAN 

less-than-or-equal:  INTEGER  x  INTEGER  — >  BOOLEAN 


FOOTNOTES 


*Thu3  "embedded"  Is  almost  synonymous  with  "real-time”,  but  we  prefer  the 
newer  term  because  it  does  not  exclude  performance  requirements  dealing  with 
reliability. 

**Throughout  this  paper  mappings  will  be  called  "funct tons" ,  despite  the 
fact  that  mappings  named  in  specifications  are  often  relations.  The  reason  is 
that  "function"  gives  a  more  accurate  impression:  the  intention  is  always  to 
produce  a  unique  value  when  the  mapping  is  Invoked  in  the  eventual  target 
system,  even  though  that  value  cannot  always  be  determined  by  a  known 
functional  expression. 

^^^This  Is  actually  an  inference  from  the  requirements  document,  which  is 
by  no  means  clear  on  this  point. 

****For  interpretable  languages,  "fixed"  and  "bounded"  always  mean  the 
same  thing,  because  the  programmer  declares  structures  sized  up  to  the  bound, 
and  then  uses  as  much  of  them  as  needed. 

*****More  generally,  the  sequence  of  evaluations  of  the  function  over  the 
lifetime  of  the  system  could  be  associated  with  a  stochastic  process,  so  that 
the  tine  of  each  evaluation  would  be  a  separate  random  variable,  but  let  us 
hope  such  generality  will  never  be  needed. 
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Figure  2.  A  requlrements-level  system  classification 


Figure  3.  The  AFWET  system. 
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Figure  11.  The  time  scheme  of  AFV.'ET. 
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Figure  12.  AFVET  processes  Involved  In  simulation. 
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Figure  13.  The  conceptual  model  underlying  both  process-oriented  and 
data-oriented  approaches. 
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Figure  14.  The  three  types  of  exchange  functions. 
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